Hi, I'm in favor of keeping the the "external PSK" option. Just like with IPSec, PSKs are easier to handle than certificates for most installations. PSKs simpifiy lab setups, make getting started easier, and are pretty robust -- no time dependency, and no need for renewals (right now I'm not quite sure whether the latter's a pro or con).
I don't know about compliance-relevant standards (FIPS?), there might be conflicts. On the network access device it might seem advisable to store the PSKs in some system-only "private storage" (similiar to SNMPv3 credentials or cert private keys). Cheers, Marc On 08.07.2024 14:51, Joe Clarke (jclarke) wrote:
I am speaking as a contributor and user of TACACS+ in general. I am not personally implementing a T+ server or this draft. I think fully supporting and documenting external PSKs would be generally useful and would possibly aid in the adoption of this new modality for T+. I would be in favor of option 2. I would also like to hear from people like Rod Persky and Marc Huber who mentioned possible implementations. === As a chair, I’m glad to see this email this morning. Going into today I was a bit conflicted as to how to decide this WG LC. We received some feedback, but nothing overwhelming to point to consensus. I was thinking to push it back to the WG to settle on this and look to do another WG LC. It seems you preempted me. Additionally, I did not receive any replies to the renewed IPR call. We want to make sure all IPR has been disclosed (if there is any) prior to WG LC conclusion. Joe *From: *Douglas Gash (dcmgash) <dcmg...@cisco.com> *Date: *Monday, July 8, 2024 at 04:48 *To: *mohamed.boucad...@orange.com <mohamed.boucad...@orange.com>, Joe Clarke (jclarke) <jcla...@cisco.com>, Alan DeKok <al...@deployingradius.com>, opsawg@ietf.org <opsawg@ietf.org> *Cc: *Thorsten Dahm <thorsten.d...@gmail.com>, John Heasly <h...@shrubbery.net>, Andrej Ota <and...@ota.si> *Subject: *Re: OPSAWG Digest, Vol 205, Issue 20 Dear Opsawg et al, 1) Discussion on External PSK (Related to part of Mohamed’s point 2 below). Our distillation of the thrust of Alan’s main advice is: The doc needs to either commit to fully documenting external PSK and its ramifications or preclude it. The truth is, our doc merely says: TLS T+ implementations may support External PSK, and leaves it there. Background: as this doc has evolved, we have temporized on the topic for the first TLS version of T+. On one side: we were not convinced External PSKs are quite established in TLS 1.3. On the other side they would be very useful for operators. But now It seems that PSKs have become better established, through the work of Alan et al, so we may consider to document use of External for this initial doc, rather than adding later supplement to cover external PSK. It does mean through that there may be another round or two to bring in the needed details. So now would be a good point to gauge the opinion of the group. Based upon where the doc is in the process, and what changes should be applied to it at this time:: 1) Should we revert the doc to say: “External PSK should not be used now. A supplement will follow to address how PSK can be used properly” Or 2) Keep the option for External PSKs to be used as now, and Commit to a few rounds of revisions to document to fully flesh out its support. Authors would be happy either way, probably on balance we would prefer second option, If we went for option 2), then below is an outline of the responses which we believe would cover External PSK: Note: “RADIUS and TLS-PSK” Provides a wealth of recommendations on PSKs. 1.a new section will be added specific to PSKs include the following items, mainly gleaned from “RADIUS and TLS-PSK”, (note that TLS 1.2 related issues have been filtered out) General: It is RECOMMENDED that systems follow the directions of [RFC9257 <https://www.ietf.org/archive/id/draft-dekok-radext-tls-psk-01.html#RFC9257>] Section 4 PSK length recommendations for both implementation and operations Fortunately, as we have already removed the MD5 obfuscation, we do not have issues in sharing Shared secrets and PSKs PSK Identity: RFC9257 <https://www.ietf.org/archive/id/draft-dekok-radext-tls-psk-01.html#RFC9257> 6.1 to be used for PSK identities PSK Identity length recommendations for both implementations and operations. Per Client Sharing PSK must be unique per client as configured on server PSK Identities must be unique per client as configured on server (Of course references will be updated to acknowledge this doc) 2.The Tacacss draft doc mentions identity specifically in the context of Certificates. This will be clarified that it applies only to certificate based, and for PSK it has its own guidance as above. The following changes are not directly related to External PSK and will be resolved anyway: 2) Resumption elements from RFC9190 (Related to the balance of Mohamed’s point 2 below). References from RFC9190. The doc primarily adresses the use of TLS as an EAP option, which has extra concerns as it is used for authorization information. The concerns that were apprehended form the text are listed below with our evaluation of relevance when used for the tacacss security wrapper. Authorization on resumption mased on cached data rather than the data in the resumption: Regarded: Not Relevant as the data is not used for authorization for tacacss Verification of certificates revoked during the period since the last “New Session Ticket Message” Regarded: Relevant, and we will update. RFC 8446 is not silent on this topic, so we will prefer to cover this by refererence to section 4.6.1 which says: Note that in principle it is possible to continue issuing new tickets which indefinitely extend the lifetime of the keying material originally derived from an initial non-PSK handshake (which was most likely tied to the peer's certificate). It is RECOMMENDED that implementations place limits on the total lifetime of such keying material; these limits should take into account the lifetime of the peer's certificate, */the likelihood of intervening revocation/*, and the time since the peer's online CertificateVerify signature. Maximum lifetime: Regarded Relevant, we will update by reference to its coveragein RFC 8446 “time-of-check time-of-use” issues Regarded: Not Relevant as the data is not used for authorization for tacacss Re evaluation of authorization on resumption: Regarded: Not Relevant as the data is not used for authorization for tacacss 3) Regarding 3) below, thanks for the catch, We’re proposing the following change: Current: To ensure separation of TACACS+ traffic that uses TLS from that which does not (Section 5.3), they will be deployed on different ports. Due to the widespread use of default port number settings in numerous existing TACACS+ client configurations, a well-known system TCP/IP port number will be requested from IANA. Client implementations can ensure traffic is kept separate. The designated port number is [TBD] (Section 7) with the service name [TBDN] (Section 7). Proposal: To ensure separation of TACACS+ traffic that uses TLS from that which does not (Section 5.3), they must be deployed on different server ports. Further, because of the widespread use of default port number settings in numerous existing TACACS+ client configurations, a well- known system TCP/IP port number is assigned: the designated port number is [TBD] (Section 7) with the service name [TBDN] (Section 7). This way the client can ensure that TLS and non TLS traffic are separated even where default ports are omitted from its server connection configuration. Date: Fri, 28 Jun 2024 13:36:42 +0000 From: mohamed.boucad...@orange.com Subject: [OPSAWG]Re: WG LC: draft-ietf-opsawg-tacacs-tls13 To: Alan DeKok <al...@deployingradius.com>, "opsawg@ietf.org" <opsawg@ietf.org> Cc: "u...@ietf.org" <u...@ietf.org>, "Joe Clarke (jclarke)" <jclarke=40cisco....@dmarc.ietf.org> Message-ID: <du2pr02mb10160c69e1af8e95168d5cc6a88...@du2pr02mb10160.eu rprd02.prod.outlook.com> Content-Type: text/plain; charset="iso-8859-1" Hi all, FWIW, we had an offline discussion with Alan and the authors to clarify the concerns. I'm reporting the main outcome of that discussion, fwiw: (1) Alan agreed that: * It is good practice to leverage existing standards * Repeating details isn't useful (2) Still, the key comment from Alan is: > My point was that the RFCs I referenced had substantial text over > and above 8446 / 9525. I asked that the authors double- check the > documents I mentioned, to see how these issues were addressed. The > result was a few minor changes. The shepherd agrees that this is a reasonable comment that should be adequately addressed. The authors engaged to have a look into the various RFCs cited by Alan and grab applicable items to tacacs+ context. It would be helpful to share the rationale for the items that they picked vs. those they considered as not relevant. (3) As a bonus, Alan provided the following comments and summary == Some grammar / clarity comments: Section 3.1: ... To ensure separation of TACACS+ traffic that uses TLS from that which does not (Section 5.3), they will be deployed on different ports. Due to the widespread use of default port number settings in numerous existing TACACS+ client configurations, a well-known system TCP/IP port number will be requested from IANA ... The text is ambiguous: "will" be requested? When? Does this document allocate the port? The usual text is to say "port TBD has been assigned for this protocol". In short: I'm not objecting to the publication of this document. My concern is that it doesn't give a lot of guidance to implementing TACACS+ over TLS. I can see basic implementations working, just by wrapping TACACS+ in TLS. But the operational considerations outlined above will have to be discovered piece-meal by implementors. == Cheers, Med ***************************************
_______________________________________________ OPSAWG mailing list -- opsawg@ietf.org To unsubscribe send an email to opsawg-le...@ietf.org
