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

[Marc Huber <[e-mail]>]

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) <[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
> ***************************************
>