[OPSAWG]Re: OPSAWG Digest, Vol 205, Issue 20

["Joe Clarke (jclarke)" <[e-mail]>]

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) <[e-mail]>
Date: Monday, July 8, 2024 at 04:48
To: [e-mail] <[e-mail]>, Joe Clarke (jclarke) <[e-mail]>, Alan DeKok <[e-mail]>, [e-mail] <[e-mail]>
Cc: Thorsten Dahm <[e-mail]>, John Heasly <[e-mail]>, Andrej Ota <[e-mail]>
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: [e-mail]
Subject: [OPSAWG]Re: WG LC: draft-ietf-opsawg-tacacs-tls13
To: Alan DeKok <[e-mail]>, "[e-mail]"
        <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, "Joe Clarke (jclarke)"
        <jclarke=[e-mail]>
Message-ID: <[e-mail]
        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
***************************************