Hi Russ, Med,
Just to confirm, there are three authentication methods (Cert, PSK, RPK). Cert
MUST be implemented, the other two MAY be implemented, as they become mature.
We have made two specific changes, which we hope will clarify:
1. We have indicated that the two options (PSK and RPK) are alternatives to
Cert based, to avoid the impression that they are augmentations which are
intended to work in combination.
2. In the start of the Cert based section, we have clarified that this
section covers Cert based only.
Please let us know if this new version changes clarify this intent.
Many thanks!
NEW:
3.3. TLS Authentication Options
Implementations MUST support certificate based mutual authentication,
to provide a core option for interoperability between deployments.
This authentication option is specified in Section 3.4.
In addition to certificate-based TLS authentication,
implementations MAY support the following alternative authentication
mechanisms:
* Pre-Shared Keys (PSKs) (Section 3.5), also known as external PSKs
in TLS 1.3
* Raw Public Keys (RPK). There is no definitive description of Raw
Public Keys in TLS 1.3 at time of writing, so [RFC7250] must be
used in context of [RFC8446]. The details of RPK are considered
out-of-scope for this document. Please refer to the RFCs above
for implementation, deployment, and security considerations.
3.4. TLS Certificate Authentication
TLS certificate authentication is the primary authentication
option for TACACS+ over TLS. This section covers certificate
authentication only.
Deploying TLS Certificate Authentication correctly will considerably
improve the security of TACACS+ deployments. It is essential for
OLD:
3.3. TLS Authentication Options
Implementations MUST support Certificate based mutual authentication.
In addition to full certificate-based TLS authentication,
implementations MAY support:
* Pre-Shared Keys (PSKs) (Section 3.5), also known as external PSKs
in TLS 1.3
* Raw Public Keys (RPK). There is no definitive description of Raw
Public Keys in TLS 1.3 at time of writing, so [RFC7250] must be
used in context of [RFC8446]. The details of RPK are considered
out-of-scope for this document. Please refer to the RFCs above
for implementation, deployment, and security considerations.
3.4. TLS Certificate Authentication
Deploying TLS Certificate Authentication correctly will considerably
improve the security of TACACS+ deployments. It is essential for
From: Russ Housley <hous...@vigilsec.com>
Date: Sunday, 9 March 2025 at 18:06
To: mohamed.boucad...@orange.com <mohamed.boucad...@orange.com>
Cc: IETF SecDir <sec...@ietf.org>, draft-ietf-opsawg-tacacs-tls13....@ietf.org
<draft-ietf-opsawg-tacacs-tls13....@ietf.org>, last-c...@ietf.org
<last-c...@ietf.org>, opsawg@ietf.org <opsawg@ietf.org>
Subject: Re: [Last-Call] Secdir last call review of
draft-ietf-opsawg-tacacs-tls13-18
Med:
The document has a MUST statement about mutual certificate-based
authentication, and then it talks about two approaches that do not use
certificates. That is my complaint. The proposed chages do not address the
core concerns.
I do not have clarity about what the authors intend. Perhaps they mean that
there are three options for authentication. One of them MUST be used. For
interoperability, all implementations MUST implement mutual certificate-based
authentication. If that is the intent, I can support it, but that is not what
I see in the document.
Russ
> On Mar 9, 2025, at 5:44 AM, mohamed.boucad...@orange.com wrote:
>
> Hi Russ,
>
> Please see inline.
>
> Cheers,
> Med (as doc Shepherd)
>
>> -----Message d'origine-----
>> De : Russ Housley via Datatracker <nore...@ietf.org>
>> Envoyé : dimanche 9 mars 2025 02:17
>> À : sec...@ietf.org
>> Cc : draft-ietf-opsawg-tacacs-tls13....@ietf.org; last-c...@ietf.org;
>> opsawg@ietf.org
>> Objet : Secdir last call review of draft-ietf-opsawg-tacacs-tls13-18
>>
>>
>> Reviewer: Russ Housley
>> Review result: Not Ready
>>
>> I reviewed this document as part of the Security Directorate's ongoing
>> effort to review all IETF documents being processed by the IESG.
>> These comments were written primarily for the benefit of the Security
>> Area Directors. Document authors, document editors, and WG chairs
>> should treat these comments just like any other IETF Last Call
>> comments.
>>
>> Document: draft-ietf-opsawg-tacacs-tls13-18
>> Reviewer: Russ Housley
>> Review Date: 2025-03-08
>> IETF LC End Date: 2025-03-27
>> IESG Telechat date: Unknown
>>
>> Summary: Not Ready
>>
>>
>> Major Concerns:
>>
>> Section 3.3: The text requires support for "mutual authentication". I
>> assume that this means that it MUST be supported, but it does not have
>> to be used.
>
> [Med] ACK per the clarification provided by the authors to your previous
> review:
> https://mailarchive.ietf.org/arch/msg/secdir/HpnUABp1q4YbRWq5Q16VD3XRo64/
>
> However, the next section say: "Each peer MUST validate
>> the certificate path of the remote peer, ...". This seems to be in
>> conflict. It requires the use of both server certificates and client
>> certificates.
>>
>
> [Med] There are specific sections for each authentication option (3.4/3.5). I
> suggest:
>
> (1)
>
> OLD:
> Implementations MUST support Certificate based mutual authentication.
>
> NEW:
> Implementations MUST support Certificate-based mutual authentication.
> Refer to Section 3.4 for additional guidance.
>
> (2)
>
> OLD:
> 3.4. TLS Certificate Authentication
>
> NEW:
> 3.4. TLS Certificate Authentication
>
> This section is applicable when certificate-based authentication is used.
>
>
>> Section 3.3: The text says: "... full certificate-based TLS
>> authentication ...". I do not know what that means. Please clarify.
>>
>> Section 3.3: With the removal of the reference to [RFC8773], how is
>> the requirement for certificates accomplished while also using
>> external PSKs? I am unaware of any other way to do so. Further,
>> Section 3.5 describes PSK authentication as an alternative to
>> certificate-based authentication. These sections are in conflict.
>>
>> Section 3.3: The text allows the use of [RFC7250] must be used in the
>> context of [RFC8446]. How is the requirement for certificates
>> accomplished with raw public keys? I am unaware of any way to do so.
>
> [Med] For the two last points, I wonder whether you checked the context I
> provided you at
> https://mailarchive.ietf.org/arch/msg/secdir/01c9y_BUuuxEcj4I6vW9tgowjtw/?
>
> == Here is the extract of specific comments from Valery:
> 7. Section 3.2.2: referencing RFC 7250 is a bit problematic, since it
> defines using RPKs for TLS 1.2 only (and thus contains TLS 1.2 specific
> information). RPKs is also supported in TLS 1.3, but referencing this support
> is not an easy task - there is no dedicated section in RFC 8446... I don't
> have any good proposals here, perhaps just add reference to 8446 in addition
> to 7250.
> 8. Section 3.2.2: referencing RFC 8773 for PSK is incorrect. Using sole PSK
> is defined in RFC 8446, while RFC 8773 defines using PSK+Certificate.
> ==
>
>>
>>
>> Minor Concerns: None
>>
>>
>> Nits:
>>
>> Section 3.3: s/Certificate based mutual/certificate-based mutual/
>>
>>
>
> ____________________________________________________________________________________________________________
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu
> ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou
> falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete
> this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been
> modified, changed or falsified.
> Thank you.
> --
> last-call mailing list -- last-c...@ietf.org
> To unsubscribe send an email to last-call-le...@ietf.org
_______________________________________________
OPSAWG mailing list -- opsawg@ietf.org
To unsubscribe send an email to opsawg-le...@ietf.org
