[OPSAWG]Secdir last call review of draft-ietf-opsawg-tacacs-tls13-10

[Russ Housley via Datatracker]

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-10
Reviewer: Russ Housley
Review Date: 2024-07-01
IETF LC End Date: Unknown
IESG Telechat date: Unknown

Summary: Not Ready


Major Concerns:

Section 3.2.2 says: "Certificate based mutual authentication MUST be
supported."  I assume that this means that it MUST be supported, but
I does not have to be used.  However, the next sentence seems to
require certificates,

Section 3.2.2: 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.
   
Section 3.2.2 says: "...[RFC7250] must be used in context of [RFC8446]".
How is the requirement for certificates accomplished with raw public
keys?  I am unaware of any way to do so.


Minor Concerns:  None


Nits: None



___
OPSAWG mailing list -- opsawg@ietf.org
To unsubscribe send an email to opsawg-le...@ietf.org

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

[Douglas Gash (dcmgash)]

That is certainly reasonable, we will add.

From: EBALARD Arnaud 
Date: Monday, 1 July 2024 at 12:21
To: Douglas Gash (dcmgash) , opsawg@ietf.org 

Cc: Thorsten Dahm , John Heasly , 
Andrej Ota 
Subject: RE: OPSAWG Digest, Vol 205, Issue 21
Hi Douglas,

Thanks for that feedback.

As you pointed, current state of the art is to provision users and their keys 
on the devices (up to the limits those devices have in term of number of keys 
and the burden of deploying and maintaining that on a large set of equipment) 
and not to use TACACS+ at all for the first A of AAA. AFAICT, this works for 
small networks with few administrators but does not scale at all (scaling being 
the purpose of TACACS+). In practice, people may end up deploying passwords 
because the spec (RFC 8907 and tacacs-tls) do not have guidance on the possible 
impacts of doing just that.

I think that building on your comment and include what you wrote in the 
security considerations would be nice. What about explicitly stating in that 
section that current state of the art is to provision SSH pub keys on the 
devices and limit TACACSS work to authorization and accounting, and then add a 
disclaimer on the impacts of following the password way? This would be fair and 
could evolve once other drafts become RFC and allow TACACSS to take part in AAA 
w/ keys.

Cheers,

Arnaud

De : Douglas Gash (dcmgash) 
Envoyé : lundi 1 juillet 2024 10:56
À : opsawg@ietf.org; EBALARD Arnaud 
Cc : Thorsten Dahm ; John Heasly ; 
Andrej Ota 
Objet : Re: OPSAWG Digest, Vol 205, Issue 21

Hi Arnaud,

The need for enhancing the flow for SSH key authentication is clear, and the 
initial version of the document covered this to some degree.  However, after 
discussion in the group the doc was split to cover TLS (as a priority), and a 
second document that is in preparation for SSH keys.

To give a head’s up on the current direction:

The current state of art is that the SSH keys are normally provisioned on the 
devices (the AAA clients), and TACACS+ does not actually get involved with this 
authentication process, it sticks to the authorisation and the accounting.

The direction that was being taken in the doc -before the SSH stuff was split 
out-  and will be taken in the initial versions of the forthcoming separate doc 
for SSH,  allows the AAA server to select and provision the SSH keys to the 
enforcement device (AAA client) during a new TACACS+ authentication flow. The 
enforcement devices would then continue to implement the SSH end-station 
endpoint authentication as now.

In other words: the SSH authentication itself was not extended from the AAA 
client to the AAA server, just the SSH key provisioning.





Date: Mon, 1 Jul 2024 08:14:27 +
From: EBALARD Arnaud 
mailto:arnaud.ebal...@ssi.gouv.fr>>
Subject: [OPSAWG]Security Considerations regarding
draft-ietf-opsawg-tacacs-tls13
To: "opsawg@ietf.org" 
mailto:opsawg@ietf.org>>
Message-ID: 
<024067fa1d4c4269a6b472b45b0cc...@ssi.gouv.fr>
Content-Type: multipart/alternative;
boundary="_000_024067fa1d4c4269a6b472b45b0cc3bassigouvfr_"

Hi,

I would like to apologize for the late timing in providing the following 
comments.

The Security Considerations section of RFC 8907 properly describes TACACS+ 
scrambling mechanism and associated impacts. This tacacs-tls draft addresses 
*this* specific issue by replacing the scrambling mechanism by state of the art 
cryptography using TLS 1.3. It is likely that TACACSS will end up being the new 
standard to build secure AAA architecture for administrating network equipment.

To my knowledge, there is however a blind spot going down this sole path in 
that it will end up reducing the security of network architectures in which 
TACACSS will be deployed. I am not objecting to advancing this specification 
but it would be fair to properly record this blind spot in the document so that 
people can weigh the pros and cons before going all-in on TACACS+/S.

Nowadays, if one tries to implement a secure administration architecture, they 
will almost certainly consider using asymmetric keys (possibly in cryptographic 
tokens) instead of passwords for authentication to remote systems using SSH or 
HTTPS. There are various reasons for this evolution: using a signature provides 
a strong authentication, it does not leak the secret outside of the 
administrator workstation (or token), populating a remote device is a matter of 
installing a public part (key for SSH, CA for X.509 certs) instead of 
manipulating a password or a salted hash, etc. On the contrary, when a user 
logs onto a system using a password, the (possibly compromised) remote system 
gets access to that password. The blind spot with TACACS+/S is that the 
protocol only supports passwords as its authentication mechanism and thus 
currently comes with a security price for the functionalities it provides. It 
gets even worse because thi

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

[EBALARD Arnaud]

Hi Douglas,

Thanks for that feedback.

As you pointed, current state of the art is to provision users and their keys 
on the devices (up to the limits those devices have in term of number of keys 
and the burden of deploying and maintaining that on a large set of equipment) 
and not to use TACACS+ at all for the first A of AAA. AFAICT, this works for 
small networks with few administrators but does not scale at all (scaling being 
the purpose of TACACS+). In practice, people may end up deploying passwords 
because the spec (RFC 8907 and tacacs-tls) do not have guidance on the possible 
impacts of doing just that.

I think that building on your comment and include what you wrote in the 
security considerations would be nice. What about explicitly stating in that 
section that current state of the art is to provision SSH pub keys on the 
devices and limit TACACSS work to authorization and accounting, and then add a 
disclaimer on the impacts of following the password way? This would be fair and 
could evolve once other drafts become RFC and allow TACACSS to take part in AAA 
w/ keys.

Cheers,

Arnaud

De : Douglas Gash (dcmgash) 
Envoyé : lundi 1 juillet 2024 10:56
À : opsawg@ietf.org; EBALARD Arnaud 
Cc : Thorsten Dahm ; John Heasly ; 
Andrej Ota 
Objet : Re: OPSAWG Digest, Vol 205, Issue 21

Hi Arnaud,

The need for enhancing the flow for SSH key authentication is clear, and the 
initial version of the document covered this to some degree.  However, after 
discussion in the group the doc was split to cover TLS (as a priority), and a 
second document that is in preparation for SSH keys.

To give a head's up on the current direction:

The current state of art is that the SSH keys are normally provisioned on the 
devices (the AAA clients), and TACACS+ does not actually get involved with this 
authentication process, it sticks to the authorisation and the accounting.

The direction that was being taken in the doc -before the SSH stuff was split 
out-  and will be taken in the initial versions of the forthcoming separate doc 
for SSH,  allows the AAA server to select and provision the SSH keys to the 
enforcement device (AAA client) during a new TACACS+ authentication flow. The 
enforcement devices would then continue to implement the SSH end-station 
endpoint authentication as now.

In other words: the SSH authentication itself was not extended from the AAA 
client to the AAA server, just the SSH key provisioning.





Date: Mon, 1 Jul 2024 08:14:27 +
From: EBALARD Arnaud 
mailto:arnaud.ebal...@ssi.gouv.fr>>
Subject: [OPSAWG]Security Considerations regarding
draft-ietf-opsawg-tacacs-tls13
To: "opsawg@ietf.org" 
mailto:opsawg@ietf.org>>
Message-ID: 
<024067fa1d4c4269a6b472b45b0cc...@ssi.gouv.fr>
Content-Type: multipart/alternative;
boundary="_000_024067fa1d4c4269a6b472b45b0cc3bassigouvfr_"

Hi,

I would like to apologize for the late timing in providing the following 
comments.

The Security Considerations section of RFC 8907 properly describes TACACS+ 
scrambling mechanism and associated impacts. This tacacs-tls draft addresses 
*this* specific issue by replacing the scrambling mechanism by state of the art 
cryptography using TLS 1.3. It is likely that TACACSS will end up being the new 
standard to build secure AAA architecture for administrating network equipment.

To my knowledge, there is however a blind spot going down this sole path in 
that it will end up reducing the security of network architectures in which 
TACACSS will be deployed. I am not objecting to advancing this specification 
but it would be fair to properly record this blind spot in the document so that 
people can weigh the pros and cons before going all-in on TACACS+/S.

Nowadays, if one tries to implement a secure administration architecture, they 
will almost certainly consider using asymmetric keys (possibly in cryptographic 
tokens) instead of passwords for authentication to remote systems using SSH or 
HTTPS. There are various reasons for this evolution: using a signature provides 
a strong authentication, it does not leak the secret outside of the 
administrator workstation (or token), populating a remote device is a matter of 
installing a public part (key for SSH, CA for X.509 certs) instead of 
manipulating a password or a salted hash, etc. On the contrary, when a user 
logs onto a system using a password, the (possibly compromised) remote system 
gets access to that password. The blind spot with TACACS+/S is that the 
protocol only supports passwords as its authentication mechanism and thus 
currently comes with a security price for the functionalities it provides. It 
gets even worse because this password will end up being valid for all the 
equipment under the TACACS+/S server control. Hence, a single compromised 
system in a TACACS+/S environment leads to the compromise of the whole domain.

Until TACACS+/S evolves to deprecate p

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

[Douglas Gash (dcmgash)]

Hi Arnaud,

The need for enhancing the flow for SSH key authentication is clear, and the 
initial version of the document covered this to some degree.  However, after 
discussion in the group the doc was split to cover TLS (as a priority), and a 
second document that is in preparation for SSH keys.

To give a head’s up on the current direction:

The current state of art is that the SSH keys are normally provisioned on the 
devices (the AAA clients), and TACACS+ does not actually get involved with this 
authentication process, it sticks to the authorisation and the accounting.

The direction that was being taken in the doc -before the SSH stuff was split 
out-  and will be taken in the initial versions of the forthcoming separate doc 
for SSH,  allows the AAA server to select and provision the SSH keys to the 
enforcement device (AAA client) during a new TACACS+ authentication flow. The 
enforcement devices would then continue to implement the SSH end-station 
endpoint authentication as now.

In other words: the SSH authentication itself was not extended from the AAA 
client to the AAA server, just the SSH key provisioning.





Date: Mon, 1 Jul 2024 08:14:27 +
From: EBALARD Arnaud 
Subject: [OPSAWG]Security Considerations regarding
draft-ietf-opsawg-tacacs-tls13
To: "opsawg@ietf.org" 
Message-ID: <024067fa1d4c4269a6b472b45b0cc...@ssi.gouv.fr>
Content-Type: multipart/alternative;
boundary="_000_024067fa1d4c4269a6b472b45b0cc3bassigouvfr_"

Hi,

I would like to apologize for the late timing in providing the following 
comments.

The Security Considerations section of RFC 8907 properly describes TACACS+ 
scrambling mechanism and associated impacts. This tacacs-tls draft addresses 
*this* specific issue by replacing the scrambling mechanism by state of the art 
cryptography using TLS 1.3. It is likely that TACACSS will end up being the new 
standard to build secure AAA architecture for administrating network equipment.

To my knowledge, there is however a blind spot going down this sole path in 
that it will end up reducing the security of network architectures in which 
TACACSS will be deployed. I am not objecting to advancing this specification 
but it would be fair to properly record this blind spot in the document so that 
people can weigh the pros and cons before going all-in on TACACS+/S.

Nowadays, if one tries to implement a secure administration architecture, they 
will almost certainly consider using asymmetric keys (possibly in cryptographic 
tokens) instead of passwords for authentication to remote systems using SSH or 
HTTPS. There are various reasons for this evolution: using a signature provides 
a strong authentication, it does not leak the secret outside of the 
administrator workstation (or token), populating a remote device is a matter of 
installing a public part (key for SSH, CA for X.509 certs) instead of 
manipulating a password or a salted hash, etc. On the contrary, when a user 
logs onto a system using a password, the (possibly compromised) remote system 
gets access to that password. The blind spot with TACACS+/S is that the 
protocol only supports passwords as its authentication mechanism and thus 
currently comes with a security price for the functionalities it provides. It 
gets even worse because this password will end up being valid for all the 
equipment under the TACACS+/S server control. Hence, a single compromised 
system in a TACACS+/S environment leads to the compromise of the whole domain.

Until TACACS+/S evolves to deprecate password-based authentication mechanisms 
in favor of state of the art ones (such as SSH public keys, etc), the Security 
Considerations section of the draft should mention the limitations associated 
with using TACACSS as is. If the WG agrees with my assessment, I can propose 
some text to highlight the concern.

Comments are welcome,

Cheers,

Arnaud

Les donn?es ? caract?re personnel recueillies et trait?es dans le cadre de cet 
?change, le sont ? seule fin d'ex?cution d'une relation professionnelle et 
s'op?rent dans cette seule finalit? et pour la dur?e n?cessaire ? cette 
relation. Si vous souhaitez faire usage de vos droits de consultation, de 
rectification et de suppression de vos donn?es, veuillez contacter 
contact.r...@sgdsn.gouv.fr. Si vous avez re?u ce message par erreur, nous vous 
remercions d'en informer l'exp?diteur et de d?truire le message. The personal 
data collected and processed during this exchange aims solely at completing a 
business relationship and is limited to the necessary duration of that 
relationship. If you wish to use your rights of consultation, rectification and 
deletion of your data, please contact: contact.r...@sgdsn.gouv.fr. If you have 
received this message in error, we thank you for informing the sender and 
destroying the message.
-- next part --
A message part incompatible with plain text digests has been removed ...
Name: not available
Type: text/html
Size: 6

[OPSAWG]Re: 🔔 WG Adoption Call for draft-gfz-opsawg-ipfix-alt-mark-01

[Mauro Cociglio]

Dear All,

I support the adoption of this draft.

Regards.

Mauro Cociglio



-Original Message-

From: Henk Birkholz 
mailto:henk.birkholz@ietf.contact>>

Sent: Wednesday, June 26, 2024 11:59 AM

To: OPSAWG mailto:opsawg@ietf.org>>

Subject: [OPSAWG]🔔 WG Adoption Call for draft-gfz-opsawg-ipfix-alt-mark-01



Dear OPSAWG members,



this email starts a call for Working Group Adoption of



> https://datatracker.ietf.org/doc/html/draft-gfz-opsawg-ipfix-alt-mark-

> 01



ending on Saturday, July 6th. That is a little bit of an odd duration, but the 
I-D is crisp and concise and if there is rough consensus after that time, this 
work may become a WG item before the upcoming cut-off.



As a reminder, this I-D specifies IPFIX Information Elements for the 
Alternate-Marking Method as defined in RFC9341 & RFC9342; a technique for 
measuring packet loss, delay, and jitter of packets in-flight.



The chairs acknowledge positive feedback and some review on the list and we 
would like to gather feedback from the WG if there is interest to further 
contribute and review.



Please reply with your support and especially any substantive comments you may 
have.





For the OPSAWG co-chairs,



Henk



___

OPSAWG mailing list -- opsawg@ietf.org

To unsubscribe send an email to 
opsawg-le...@ietf.org

___
OPSAWG mailing list -- opsawg@ietf.org
To unsubscribe send an email to opsawg-le...@ietf.org

[OPSAWG]Security Considerations regarding draft-ietf-opsawg-tacacs-tls13

[EBALARD Arnaud]

Hi,

I would like to apologize for the late timing in providing the following 
comments.

The Security Considerations section of RFC 8907 properly describes TACACS+ 
scrambling mechanism and associated impacts. This tacacs-tls draft addresses 
*this* specific issue by replacing the scrambling mechanism by state of the art 
cryptography using TLS 1.3. It is likely that TACACSS will end up being the new 
standard to build secure AAA architecture for administrating network equipment.

To my knowledge, there is however a blind spot going down this sole path in 
that it will end up reducing the security of network architectures in which 
TACACSS will be deployed. I am not objecting to advancing this specification 
but it would be fair to properly record this blind spot in the document so that 
people can weigh the pros and cons before going all-in on TACACS+/S.

Nowadays, if one tries to implement a secure administration architecture, they 
will almost certainly consider using asymmetric keys (possibly in cryptographic 
tokens) instead of passwords for authentication to remote systems using SSH or 
HTTPS. There are various reasons for this evolution: using a signature provides 
a strong authentication, it does not leak the secret outside of the 
administrator workstation (or token), populating a remote device is a matter of 
installing a public part (key for SSH, CA for X.509 certs) instead of 
manipulating a password or a salted hash, etc. On the contrary, when a user 
logs onto a system using a password, the (possibly compromised) remote system 
gets access to that password. The blind spot with TACACS+/S is that the 
protocol only supports passwords as its authentication mechanism and thus 
currently comes with a security price for the functionalities it provides. It 
gets even worse because this password will end up being valid for all the 
equipment under the TACACS+/S server control. Hence, a single compromised 
system in a TACACS+/S environment leads to the compromise of the whole domain.

Until TACACS+/S evolves to deprecate password-based authentication mechanisms 
in favor of state of the art ones (such as SSH public keys, etc), the Security 
Considerations section of the draft should mention the limitations associated 
with using TACACSS as is. If the WG agrees with my assessment, I can propose 
some text to highlight the concern.

Comments are welcome,

Cheers,

Arnaud

Les donn?es ? caract?re personnel recueillies et trait?es dans le cadre de cet 
?change, le sont ? seule fin d'ex?cution d'une relation professionnelle et 
s'op?rent dans cette seule finalit? et pour la dur?e n?cessaire ? cette 
relation. Si vous souhaitez faire usage de vos droits de consultation, de 
rectification et de suppression de vos donn?es, veuillez contacter 
contact.r...@sgdsn.gouv.fr. Si vous avez re?u ce message par erreur, nous vous 
remercions d'en informer l'exp?diteur et de d?truire le message. The personal 
data collected and processed during this exchange aims solely at completing a 
business relationship and is limited to the necessary duration of that 
relationship. If you wish to use your rights of consultation, rectification and 
deletion of your data, please contact: contact.r...@sgdsn.gouv.fr. If you have 
received this message in error, we thank you for informing the sender and 
destroying the message.
___
OPSAWG mailing list -- opsawg@ietf.org
To unsubscribe send an email to opsawg-le...@ietf.org