[OPSAWG]Re: I-D Action: draft-ietf-opsawg-pcaplinktype-06.txt

[Michael Richardson]

Hi, so I posted -08 of pcaplinktype in an attempt to correct the HTML, but
that didn't work.  I upgraded to xml2rfc 3.25 locally, and I get mixed results.
I asked online, and was told that there are CSS issues with the HTML produced
on the DT, and I've filed a bug report.  The TXT file (and XML) are correct
and readable.

I'd really like feedback about swapping the FCFS/Specification Required 
allocations.

--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide






signature.asc
Description: PGP signature
___
OPSAWG mailing list -- opsawg@ietf.org
To unsubscribe send an email to opsawg-le...@ietf.org

[OPSAWG]Re: I-D Action: draft-ietf-opsawg-pcaplinktype-06.txt

[Michael Richardson]

> Some minor proposed changes can be found at:
> 
https://github.com/IETF-OPSAWG-WG/draft-ietf-opsawg-pcap/compare/master...boucadair:draft-ietf-opsawg-pcap:patch-3.

Merged.

> For the various url ref entries with "n,d", may be better to set "date: 
false".

okay, I'll do that.
My understanding, for references to URLs, that the date should be the date at
which we last viewed the link.  I think I'll let the RPC determine this.


--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide






signature.asc
Description: PGP signature
___
OPSAWG mailing list -- opsawg@ietf.org
To unsubscribe send an email to opsawg-le...@ietf.org

[OPSAWG]Re: I-D Action: draft-ietf-opsawg-pcaplinktype-06.txt

[Guy Harris]

On Nov 26, 2024, at 8:40 AM, Michael Richardson  wrote:

> Hi, so I posted -08 of pcaplinktype in an attempt to correct the HTML, but
> that didn't work.  I upgraded to xml2rfc 3.25 locally, and I get mixed 
> results.
> I asked online, and was told that there are CSS issues with the HTML produced
> on the DT, and I've filed a bug report.  The TXT file (and XML) are correct
> and readable.

The document at

https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-pcaplinktype

lacks blank lines between the link-layer type stanzas.

However, the "txt" button in the "Other formats" section links to

https://www.ietf.org/archive/id/draft-ietf-opsawg-pcaplinktype-08.txt

which *does* have blank lines between the stanzas.

On the other hand, the "html" button links to

https://www.ietf.org/archive/id/draft-ietf-opsawg-pcaplinktype-08.html

which has blank lines between the lines *in* the stanzas, but no extra blank 
lines between the stanzas.

The "Editor's Copy" text version at


https://ietf-opsawg-wg.github.io/draft-ietf-opsawg-pcap/draft-ietf-opsawg-pcaplinktype.txt

resembles the draft-ietf-opsawg-pcaplinktype-08.txt version, but the HTML 
version at


https://ietf-opsawg-wg.github.io/draft-ietf-opsawg-pcap/draft-ietf-opsawg-pcaplinktype.html

doesn't have the issue that the draft-ietf-opsawg-pcaplinktype-08.html version 
does.

The HTML version problems might be the CSS issues you refer to.

I'm not sure what produces the

https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-pcaplinktype

as it looks like an "HTMLized text" version, using fixed-width text but 
containing links.  I'm not sure what produces that.
___
OPSAWG mailing list -- opsawg@ietf.org
To unsubscribe send an email to opsawg-le...@ietf.org

[OPSAWG]Re: [IANA #1402725] expert review for draft-ietf-opsawg-teas-common-ac (xml-registry)

[Martin Thomson]

LGTM

On Wed, Nov 27, 2024, at 10:47, David Dong via RT wrote:
> Dear Tim Bray, Martin Thomson (cc: opsawg WG),
>
> As the designated experts for the IETF XML Registry registry, can you 
> review the proposed registration in draft-ietf-opsawg-teas-common-ac-13 
> for us? Please see
>
> https://datatracker.ietf.org/doc/draft-ietf-opsawg-teas-common-ac/
>
> The due date is December 10th.
>
> If this is OK, when the IESG approves the document for publication, 
> we'll make the registration at:
>
> https://www.iana.org/assignments/xml-registry/
>
> Unless you ask us to wait for the other reviewer, we’ll act on the 
> first response we receive.
>
> With thanks,
>
> David Dong
> IANA Services Sr. Specialist

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

[OPSAWG][IANA #1402437] expert review for draft-ietf-opsawg-teas-attachment-circuit (xml-registry)

[David Dong via RT]

Dear Tim Bray, Martin Thomson (cc: opsawg WG),

As the designated experts for the IETF XML Registry registry, can you review 
the proposed registration in draft-ietf-opsawg-teas-attachment-circuit-18 for 
us? Please see

https://datatracker.ietf.org/doc/draft-ietf-opsawg-teas-attachment-circuit/

The due date is December 10th.

If this is OK, when the IESG approves the document for publication, we'll make 
the registration at:

https://www.iana.org/assignments/xml-registry/

Unless you ask us to wait for the other reviewer, we’ll act on the first 
response we receive.

With thanks,

David Dong
IANA Services Sr. Specialist

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

[OPSAWG][IANA #1402413] expert review for draft-ietf-opsawg-ntw-attachment-circuit (xml-registry)

[David Dong via RT]

Dear Tim Bray, Martin Thomson (cc: opsawg WG),

As the designated experts for the IETF XML Registry registry, can you review 
the proposed registration in draft-ietf-opsawg-ntw-attachment-circuit-14 for 
us? Please see

https://datatracker.ietf.org/doc/draft-ietf-opsawg-ntw-attachment-circuit/

The due date is December 10th.

If this is OK, when the IESG approves the document for publication, we'll make 
the registration at:

https://www.iana.org/assignments/xml-registry/

Unless you ask us to wait for the other reviewer, we’ll act on the first 
response we receive.

With thanks,

David Dong
IANA Services Sr. Specialist

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

[OPSAWG]Re: [IANA #1402413] expert review for draft-ietf-opsawg-ntw-attachment-circuit (xml-registry)

[Martin Thomson]

LGTM

On Wed, Nov 27, 2024, at 10:39, David Dong via RT wrote:
> Dear Tim Bray, Martin Thomson (cc: opsawg WG),
>
> As the designated experts for the IETF XML Registry registry, can you 
> review the proposed registration in 
> draft-ietf-opsawg-ntw-attachment-circuit-14 for us? Please see
>
> https://datatracker.ietf.org/doc/draft-ietf-opsawg-ntw-attachment-circuit/
>
> The due date is December 10th.
>
> If this is OK, when the IESG approves the document for publication, 
> we'll make the registration at:
>
> https://www.iana.org/assignments/xml-registry/
>
> Unless you ask us to wait for the other reviewer, we’ll act on the 
> first response we receive.
>
> With thanks,
>
> David Dong
> IANA Services Sr. Specialist

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

[OPSAWG]Re: [IANA #1402437] expert review for draft-ietf-opsawg-teas-attachment-circuit (xml-registry)

[Martin Thomson]

LGTM

On Wed, Nov 27, 2024, at 10:42, David Dong via RT wrote:
> Dear Tim Bray, Martin Thomson (cc: opsawg WG),
>
> As the designated experts for the IETF XML Registry registry, can you 
> review the proposed registration in 
> draft-ietf-opsawg-teas-attachment-circuit-18 for us? Please see
>
> https://datatracker.ietf.org/doc/draft-ietf-opsawg-teas-attachment-circuit/
>
> The due date is December 10th.
>
> If this is OK, when the IESG approves the document for publication, 
> we'll make the registration at:
>
> https://www.iana.org/assignments/xml-registry/
>
> Unless you ask us to wait for the other reviewer, we’ll act on the 
> first response we receive.
>
> With thanks,
>
> David Dong
> IANA Services Sr. Specialist

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

[OPSAWG][IANA #1402725] expert review for draft-ietf-opsawg-teas-common-ac (xml-registry)

[David Dong via RT]

Dear Tim Bray, Martin Thomson (cc: opsawg WG),

As the designated experts for the IETF XML Registry registry, can you review 
the proposed registration in draft-ietf-opsawg-teas-common-ac-13 for us? Please 
see

https://datatracker.ietf.org/doc/draft-ietf-opsawg-teas-common-ac/

The due date is December 10th.

If this is OK, when the IESG approves the document for publication, we'll make 
the registration at:

https://www.iana.org/assignments/xml-registry/

Unless you ask us to wait for the other reviewer, we’ll act on the first 
response we receive.

With thanks,

David Dong
IANA Services Sr. Specialist

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

[OPSAWG]Re: draft-ietf-opsawg-tacacs-tls13: Debugging TACACS+ over TLS

[Heikki Vatiainen]

Hello Med,

yes, TLS keylog is a very powerful and dangerous tool and needs to be used
with care. Where I thought it would be primarily be used is a test or
staging environment where configurations are built, updated and tested
before brought to production. If a tool, such as Wireshark, is used to help
with this now, I'd say it would be useful to hint TACACS+ users and client
and servers developers about the options they have when building
configurations that use TLS.

What I'm thinking is that what can be done to help switching to TLS when it
becomes available. At the moment everything is directly visible on the
wire. This has made troubleshooting very easy: just watch what's going to
if server or client debug logging does now help. With TLS 1.3 only the
beginning of the handshake can be snooped directly before encryption is
switched on. This is a very, very good thing and if users know how to do
debugging with TLS, my hope is that it will make TLS adaptation faster.

I understand why recommending TLS keylog in production can not be done.
Could it be mentioned as a tool when developing and testing TLS enabled
configurations?

Thanks,
Heikki

On Tue, 26 Nov 2024 at 08:28,  wrote:

> Hi Heikki,
>
>
>
> I have one comment about the suggestion to indicate that
> draft-ietf-tls-keylogfile is a better option.
>
>
>
> That spec says actually the following:
>
>
>
>This format is intended for use in
>
>systems where TLS only protects test data.  While the access that
>
>this information provides to TLS connections can be useful for
>
>diagnosing problems while developing systems, this mechanism MUST NOT
>
>be used in a production system.
>
>
>
> I’m not quite sure we can recommend this mechanism here.
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* Heikki Vatiainen 
> *Envoyé :* lundi 25 novembre 2024 19:18
> *À :* opsawg 
> *Objet :* [OPSAWG]draft-ietf-opsawg-tacacs-tls13: Debugging TACACS+ over
> TLS
>
>
>
>
>
> Would it be possible to add some text about troubleshooting TACACS+ when
> TLS is enabled? More exactly, add a reminder that TLS keylog
> https://datatracker.ietf.org/doc/draft-ietf-tls-keylogfile/ is a better
> option than:
>
>
>
> - trying to enable NULL encryption, authentication and integrity only,
> ciphers for TLSv1.3 (see RFC 9150, supported by WolfSSL and OpenSSL 3.4); or
>
> - switching to non-TLS TACACS+ connections just because of troubleshooting
>
>
>
> Any of the above alternatives would likely require configuration changes
> on the TACACS+ server and client side which may affect more connections
> than necessary. After the troubleshooting is done, any changes to TLS
> settings would also need to be reverted. This may be easy to forget leaving
> the system in insecure state.
>
>
>
> The reason why debugging is done may also relate to the TLS handshake
> itself in which case any changes to TLS settings may make the debugging
> effort useless. I.e., the attempt to observe the system changes the system
> behaviour.
>
>
>
> To provide some background, I work on AAA software named Radiator that has
> supported TACACS+ for 20+ years. From what we see, Wireshark, as an
> example, is often used to debug TACACS+. It's well-known, supports TACACS+
> well and very importantly, provides a neutral third party view of what's
> going on between the client and server. Because Wireshark also supports TLS
> keylog, it will likely continue to be a very important tool when TACACS+
> runs over TLS.
>
>
>
> Thanks to authors working on this! Please excuse me for being a bit late
> for the party.
>
>
>
> --
>
> Heikki Vatiainen
> h...@radiatorsoftware.com
>
> 
> 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.
>
>

-- 
Heikki Vatiainen
h...@radiatorsoftware.com
___
OPSAWG mailing list -- opsawg@ietf.org
To unsubscribe send an email to opsawg-le...@ietf.org

[OPSAWG]Re: draft-ietf-opsawg-tacacs-tls13: Debugging TACACS+ over TLS

[Alan DeKok]

On Nov 26, 2024, at 1:28 AM, mohamed.boucad...@orange.com wrote:
> 
> Hi Heikki,
>  I have one comment about the suggestion to indicate that 
> draft-ietf-tls-keylogfile is a better option.
>  That spec says actually the following:
> This format is intended for use in
>systems where TLS only protects test data.  While the access that
>this information provides to TLS connections can be useful for
>diagnosing problems while developing systems, this mechanism MUST NOT
>be used in a production system.
>  I’m not quite sure we can recommend this mechanism here.

  The "MUST NOT" above is for administrators, not implementers.

  It's perfectly fine for an implementation to support SSLKEYLOGFILE.  In fact, 
implementations must support it in order for it to be used in a test 
environment.

  I agree with Heikki here, it's a very good idea to recommendation that 
implementations support it, with a caveat that adminstrators do not enable it 
in production.

  Alan DeKok.


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

[OPSAWG]Re: draft-ietf-opsawg-tacacs-tls13: Debugging TACACS+ over TLS

[mohamed . boucadair]

Hi Heikki,

Thanks.

Having an **informative** reference to SSLKEYLOGFILE with a **caution** 
pointing to the applicability scope seems OK to me.

Cheers,
Med

De : Heikki Vatiainen 
Envoyé : mardi 26 novembre 2024 11:52
À : BOUCADAIR Mohamed INNOV/NET 
Cc : opsawg 
Objet : Re: [OPSAWG]draft-ietf-opsawg-tacacs-tls13: Debugging TACACS+ over TLS

Hello Med,

yes, TLS keylog is a very powerful and dangerous tool and needs to be used with 
care. Where I thought it would be primarily be used is a test or staging 
environment where configurations are built, updated and tested before brought 
to production. If a tool, such as Wireshark, is used to help with this now, I'd 
say it would be useful to hint TACACS+ users and client and servers developers 
about the options they have when building configurations that use TLS.

What I'm thinking is that what can be done to help switching to TLS when it 
becomes available. At the moment everything is directly visible on the wire. 
This has made troubleshooting very easy: just watch what's going to if server 
or client debug logging does now help. With TLS 1.3 only the beginning of the 
handshake can be snooped directly before encryption is switched on. This is a 
very, very good thing and if users know how to do debugging with TLS, my hope 
is that it will make TLS adaptation faster.

I understand why recommending TLS keylog in production can not be done. Could 
it be mentioned as a tool when developing and testing TLS enabled 
configurations?

Thanks,
Heikki

On Tue, 26 Nov 2024 at 08:28, 
mailto:mohamed.boucad...@orange.com>> wrote:
Hi Heikki,

I have one comment about the suggestion to indicate that 
draft-ietf-tls-keylogfile is a better option.

That spec says actually the following:

   This format is intended for use in
   systems where TLS only protects test data.  While the access that
   this information provides to TLS connections can be useful for
   diagnosing problems while developing systems, this mechanism MUST NOT
   be used in a production system.

I'm not quite sure we can recommend this mechanism here.

Cheers,
Med

De : Heikki Vatiainen 
mailto:h...@radiatorsoftware.com>>
Envoyé : lundi 25 novembre 2024 19:18
À : opsawg mailto:opsawg@ietf.org>>
Objet : [OPSAWG]draft-ietf-opsawg-tacacs-tls13: Debugging TACACS+ over TLS


Would it be possible to add some text about troubleshooting TACACS+ when TLS is 
enabled? More exactly, add a reminder that TLS keylog  
https://datatracker.ietf.org/doc/draft-ietf-tls-keylogfile/ is a better option 
than:

- trying to enable NULL encryption, authentication and integrity only, ciphers 
for TLSv1.3 (see RFC 9150, supported by WolfSSL and OpenSSL 3.4); or
- switching to non-TLS TACACS+ connections just because of troubleshooting

Any of the above alternatives would likely require configuration changes on the 
TACACS+ server and client side which may affect more connections than 
necessary. After the troubleshooting is done, any changes to TLS settings would 
also need to be reverted. This may be easy to forget leaving the system in 
insecure state.

The reason why debugging is done may also relate to the TLS handshake itself in 
which case any changes to TLS settings may make the debugging effort useless. 
I.e., the attempt to observe the system changes the system behaviour.

To provide some background, I work on AAA software named Radiator that has 
supported TACACS+ for 20+ years. From what we see, Wireshark, as an example, is 
often used to debug TACACS+. It's well-known, supports TACACS+ well and very 
importantly, provides a neutral third party view of what's going on between the 
client and server. Because Wireshark also supports TLS keylog, it will likely 
continue to be a very important tool when TACACS+ runs over TLS.

Thanks to authors working on this! Please excuse me for being a bit late for 
the party.

--
Heikki Vatiainen
h...@radiatorsoftware.com



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.


--
Heikki Vatiainen
h...@radiatorsoftware.com

[OPSAWG]Re: draft-ietf-opsawg-tacacs-tls13: Debugging TACACS+ over TLS

[Joe Clarke (jclarke)]

I’m glad this was brought up, and I agree mentioning this with a scope 
precaution seems wise as an operational consideration in migrating to the 
secure protocol.

Joe

From: mohamed.boucad...@orange.com 
Date: Tuesday, November 26, 2024 at 07:24
To: Heikki Vatiainen 
Cc: opsawg 
Subject: [OPSAWG]Re: draft-ietf-opsawg-tacacs-tls13: Debugging TACACS+ over TLS
Hi Heikki,

Thanks.

Having an **informative** reference to SSLKEYLOGFILE with a **caution** 
pointing to the applicability scope seems OK to me.

Cheers,
Med

De : Heikki Vatiainen 
Envoyé : mardi 26 novembre 2024 11:52
À : BOUCADAIR Mohamed INNOV/NET 
Cc : opsawg 
Objet : Re: [OPSAWG]draft-ietf-opsawg-tacacs-tls13: Debugging TACACS+ over TLS

Hello Med,

yes, TLS keylog is a very powerful and dangerous tool and needs to be used with 
care. Where I thought it would be primarily be used is a test or staging 
environment where configurations are built, updated and tested before brought 
to production. If a tool, such as Wireshark, is used to help with this now, I'd 
say it would be useful to hint TACACS+ users and client and servers developers 
about the options they have when building configurations that use TLS.

What I'm thinking is that what can be done to help switching to TLS when it 
becomes available. At the moment everything is directly visible on the wire. 
This has made troubleshooting very easy: just watch what's going to if server 
or client debug logging does now help. With TLS 1.3 only the beginning of the 
handshake can be snooped directly before encryption is switched on. This is a 
very, very good thing and if users know how to do debugging with TLS, my hope 
is that it will make TLS adaptation faster.

I understand why recommending TLS keylog in production can not be done. Could 
it be mentioned as a tool when developing and testing TLS enabled 
configurations?

Thanks,
Heikki

On Tue, 26 Nov 2024 at 08:28, 
mailto:mohamed.boucad...@orange.com>> wrote:
Hi Heikki,

I have one comment about the suggestion to indicate that 
draft-ietf-tls-keylogfile is a better option.

That spec says actually the following:

   This format is intended for use in
   systems where TLS only protects test data.  While the access that
   this information provides to TLS connections can be useful for
   diagnosing problems while developing systems, this mechanism MUST NOT
   be used in a production system.

I’m not quite sure we can recommend this mechanism here.

Cheers,
Med

De : Heikki Vatiainen 
mailto:h...@radiatorsoftware.com>>
Envoyé : lundi 25 novembre 2024 19:18
À : opsawg mailto:opsawg@ietf.org>>
Objet : [OPSAWG]draft-ietf-opsawg-tacacs-tls13: Debugging TACACS+ over TLS


Would it be possible to add some text about troubleshooting TACACS+ when TLS is 
enabled? More exactly, add a reminder that TLS keylog  
https://datatracker.ietf.org/doc/draft-ietf-tls-keylogfile/ is a better option 
than:

- trying to enable NULL encryption, authentication and integrity only, ciphers 
for TLSv1.3 (see RFC 9150, supported by WolfSSL and OpenSSL 3.4); or
- switching to non-TLS TACACS+ connections just because of troubleshooting

Any of the above alternatives would likely require configuration changes on the 
TACACS+ server and client side which may affect more connections than 
necessary. After the troubleshooting is done, any changes to TLS settings would 
also need to be reverted. This may be easy to forget leaving the system in 
insecure state.

The reason why debugging is done may also relate to the TLS handshake itself in 
which case any changes to TLS settings may make the debugging effort useless. 
I.e., the attempt to observe the system changes the system behaviour.

To provide some background, I work on AAA software named Radiator that has 
supported TACACS+ for 20+ years. From what we see, Wireshark, as an example, is 
often used to debug TACACS+. It's well-known, supports TACACS+ well and very 
importantly, provides a neutral third party view of what's going on between the 
client and server. Because Wireshark also supports TLS keylog, it will likely 
continue to be a very important tool when TACACS+ runs over TLS.

Thanks to authors working on this! Please excuse me for being a bit late for 
the party.

--
Heikki Vatiainen
h...@radiatorsoftware.com



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

[OPSAWG]Re: draft-ietf-opsawg-tacacs-tls13: Debugging TACACS+ over TLS

[mohamed . boucadair]

Hi Alan, 

I'm afraid that we need to handle this globally (e.g., in UTA WG), not for 
every application. 

For example, BCP 195 says:

  Nevertheless, this
  document does not discourage software from implementing NULL
  cipher suites, since they can be useful for testing and debugging.

Cheers,
Med

> -Message d'origine-
> De : Alan DeKok 
> Envoyé : mardi 26 novembre 2024 12:45
> À : BOUCADAIR Mohamed INNOV/NET 
> Cc : Heikki Vatiainen ; opsawg
> 
> Objet : Re: [OPSAWG]Re: draft-ietf-opsawg-tacacs-tls13: Debugging
> TACACS+ over TLS
> 
> 
> On Nov 26, 2024, at 1:28 AM, mohamed.boucad...@orange.com wrote:
> >
> > Hi Heikki,
> >  I have one comment about the suggestion to indicate that
> draft-ietf-tls-keylogfile is a better option.
> >  That spec says actually the following:
> > This format is intended for use in
> >systems where TLS only protects test data.  While the access
> that
> >this information provides to TLS connections can be useful
> for
> >diagnosing problems while developing systems, this mechanism
> MUST NOT
> >be used in a production system.
> >  I’m not quite sure we can recommend this mechanism here.
> 
>   The "MUST NOT" above is for administrators, not implementers.
> 
>   It's perfectly fine for an implementation to support
> SSLKEYLOGFILE.  In fact, implementations must support it in order
> for it to be used in a test environment.
> 
>   I agree with Heikki here, it's a very good idea to
> recommendation that implementations support it, with a caveat
> that adminstrators do not enable it in production.
> 
>   Alan DeKok.
> 


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.
___
OPSAWG mailing list -- opsawg@ietf.org
To unsubscribe send an email to opsawg-le...@ietf.org

[OPSAWG]Re: draft-ietf-opsawg-tacacs-tls13: Debugging TACACS+ over TLS

[Alan DeKok]

On Nov 26, 2024, at 7:27 AM, mohamed.boucad...@orange.com wrote:
> I'm afraid that we need to handle this globally (e.g., in UTA WG), not for 
> every application.

  I agree.

  I spoke with Eric Vyncke in Dublin, and explained that while RFC 9325 is 
good, RADIUS and TACACS+ were having similar issues with TLS.  i.e.. The TLS 
RFCs largely describe what TLS does, but are somewhat thin on how applications 
can use TLS.  The RADEXT WG has spent substantial time digging into a number of 
issues, and updating drafts with what we've found.

  His suggestion was the same as yours: This needs to be done in UTA.  He also 
pointed out that as someone involved in RADEXT, and as co-chair of UTA, I was 
the ideal person to write this document.

  The good news is that much of the necessary text is already in the RADEXT 
drafts, so perhaps the work isn't as large as it could have been,

  I'll try to find some time.

  Alan DeKok.

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

[OPSAWG]Re: draft-ietf-opsawg-tacacs-tls13: Debugging TACACS+ over TLS

[mohamed . boucadair]

Re-,

Sounds like a plan :-)

When that work is started, I'd recommend you set it under: 
https://www.rfc-editor.org/info/bcp195.

For the specific tacacs+ case, citing BCP195 instead of RFC 9325 would allow us 
to inherit these guidelines in the future. 

Thank you.

Cheers,
Med

> -Message d'origine-
> De : Alan DeKok 
> Envoyé : mardi 26 novembre 2024 13:42
> À : BOUCADAIR Mohamed INNOV/NET 
> Cc : Heikki Vatiainen ; opsawg
> 
> Objet : Re: [OPSAWG]Re: draft-ietf-opsawg-tacacs-tls13: Debugging
> TACACS+ over TLS
> 
> 
> On Nov 26, 2024, at 7:27 AM, mohamed.boucad...@orange.com wrote:
> > I'm afraid that we need to handle this globally (e.g., in UTA
> WG), not for every application.
> 
>   I agree.
> 
>   I spoke with Eric Vyncke in Dublin, and explained that while
> RFC 9325 is good, RADIUS and TACACS+ were having similar issues
> with TLS.  i.e.. The TLS RFCs largely describe what TLS does, but
> are somewhat thin on how applications can use TLS.  The RADEXT WG
> has spent substantial time digging into a number of issues, and
> updating drafts with what we've found.
> 
>   His suggestion was the same as yours: This needs to be done in
> UTA.  He also pointed out that as someone involved in RADEXT, and
> as co-chair of UTA, I was the ideal person to write this
> document.
> 
>   The good news is that much of the necessary text is already in
> the RADEXT drafts, so perhaps the work isn't as large as it could
> have been,
> 
>   I'll try to find some time.
> 
>   Alan DeKok.


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.
___
OPSAWG mailing list -- opsawg@ietf.org
To unsubscribe send an email to opsawg-le...@ietf.org

[OPSAWG]BCP 195 RE: Re: draft-ietf-opsawg-tacacs-tls13: Debugging TACACS+ over TLS

[mohamed . boucadair]

Hi Doug, all,

I remember that the draft was updated to refer to BCP195 per a comment from 
Valery 
(https://mailarchive.ietf.org/arch/msg/opsawg/U3mPq3WlRF48blMmr2uCF80KLiI/), 
however I see that there some very few places to udpate:

OLD:
   RFC9325 offers substantial guidance for implementing protocols that
   use TLS and their deployment.  Those implementing and deploying
   Secure TACACS+ must adhere to the recommendations relevant to TLS 1.3
   outlined in RFC9325, or its subsequent versions.

   This document outlines additional restrictions permissible under
   RFC9325.  For example, any recommendations referring to TLS 1.2,
   including the mandatory support, are not relevant for Secure TACACS+
   as TLS 1.3 or above is mandated.

NEW:
   [BCP195] offers substantial guidance for implementing protocols that
   use TLS and their deployment.  Those implementing and deploying
   Secure TACACS+ must adhere to the recommendations relevant to TLS 1.3
   outlined in RFC9325, or its subsequent versions.

   This document outlines additional restrictions permissible under
   [BCP195].  For example, any recommendations referring to TLS 1.2,
   including the mandatory support, are not relevant for Secure TACACS+
   as TLS 1.3 or above is mandated.

Thank you.

Cheers,
Med

> -Message d'origine-
> De : BOUCADAIR Mohamed INNOV/NET
> Envoyé : mardi 26 novembre 2024 13:49
> À : 'Alan DeKok' 
> Cc : Heikki Vatiainen ; opsawg
> 
> Objet : RE: [OPSAWG]Re: draft-ietf-opsawg-tacacs-tls13: Debugging
> TACACS+ over TLS
> 
> Re-,
> 
> Sounds like a plan :-)
> 
> When that work is started, I'd recommend you set it under:
> https://www.rfc-editor.org/info/bcp195.
> 
> For the specific tacacs+ case, citing BCP195 instead of RFC 9325
> would allow us to inherit these guidelines in the future.
> 
> Thank you.
> 
> Cheers,
> Med
> 
> > -Message d'origine-
> > De : Alan DeKok  Envoyé : mardi 26
> novembre
> > 2024 13:42 À : BOUCADAIR Mohamed INNOV/NET
> >  Cc : Heikki Vatiainen
> > ; opsawg  Objet :
> Re:
> > [OPSAWG]Re: draft-ietf-opsawg-tacacs-tls13: Debugging
> > TACACS+ over TLS
> >
> >
> > On Nov 26, 2024, at 7:27 AM, mohamed.boucad...@orange.com
> wrote:
> > > I'm afraid that we need to handle this globally (e.g., in UTA
> > WG), not for every application.
> >
> >   I agree.
> >
> >   I spoke with Eric Vyncke in Dublin, and explained that while
> RFC
> > 9325 is good, RADIUS and TACACS+ were having similar issues
> with TLS.
> > i.e.. The TLS RFCs largely describe what TLS does, but are
> somewhat
> > thin on how applications can use TLS.  The RADEXT WG has spent
> > substantial time digging into a number of issues, and updating
> drafts
> > with what we've found.
> >
> >   His suggestion was the same as yours: This needs to be done
> in UTA.
> > He also pointed out that as someone involved in RADEXT, and as
> > co-chair of UTA, I was the ideal person to write this document.
> >
> >   The good news is that much of the necessary text is already
> in the
> > RADEXT drafts, so perhaps the work isn't as large as it could
> have
> > been,
> >
> >   I'll try to find some time.
> >
> >   Alan DeKok.


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.
___
OPSAWG mailing list -- opsawg@ietf.org
To unsubscribe send an email to opsawg-le...@ietf.org

[OPSAWG]Re: BCP 195 RE: Re: draft-ietf-opsawg-tacacs-tls13: Debugging TACACS+ over TLS

[Douglas Gash (dcmgash)]

Thanks Med, good catch, we’ll add this to the next version (16)

From: mohamed.boucad...@orange.com 
Date: Tuesday, 26 November 2024 at 13:05
To: draft-ietf-opsawg-tacacs-tl...@ietf.org 

Cc: opsawg 
Subject: BCP 195 RE: [OPSAWG]Re: draft-ietf-opsawg-tacacs-tls13: Debugging 
TACACS+ over TLS
Hi Doug, all,

I remember that the draft was updated to refer to BCP195 per a comment from 
Valery 
(https://mailarchive.ietf.org/arch/msg/opsawg/U3mPq3WlRF48blMmr2uCF80KLiI/), 
however I see that there some very few places to udpate:

OLD:
   RFC9325 offers substantial guidance for implementing protocols that
   use TLS and their deployment.  Those implementing and deploying
   Secure TACACS+ must adhere to the recommendations relevant to TLS 1.3
   outlined in RFC9325, or its subsequent versions.

   This document outlines additional restrictions permissible under
   RFC9325.  For example, any recommendations referring to TLS 1.2,
   including the mandatory support, are not relevant for Secure TACACS+
   as TLS 1.3 or above is mandated.

NEW:
   [BCP195] offers substantial guidance for implementing protocols that
   use TLS and their deployment.  Those implementing and deploying
   Secure TACACS+ must adhere to the recommendations relevant to TLS 1.3
   outlined in RFC9325, or its subsequent versions.

   This document outlines additional restrictions permissible under
   [BCP195].  For example, any recommendations referring to TLS 1.2,
   including the mandatory support, are not relevant for Secure TACACS+
   as TLS 1.3 or above is mandated.

Thank you.

Cheers,
Med

> -Message d'origine-
> De : BOUCADAIR Mohamed INNOV/NET
> Envoyé : mardi 26 novembre 2024 13:49
> À : 'Alan DeKok' 
> Cc : Heikki Vatiainen ; opsawg
> 
> Objet : RE: [OPSAWG]Re: draft-ietf-opsawg-tacacs-tls13: Debugging
> TACACS+ over TLS
>
> Re-,
>
> Sounds like a plan :-)
>
> When that work is started, I'd recommend you set it under:
> https://www.rfc-editor.org/info/bcp195.
>
> For the specific tacacs+ case, citing BCP195 instead of RFC 9325
> would allow us to inherit these guidelines in the future.
>
> Thank you.
>
> Cheers,
> Med
>
> > -Message d'origine-
> > De : Alan DeKok  Envoyé : mardi 26
> novembre
> > 2024 13:42 À : BOUCADAIR Mohamed INNOV/NET
> >  Cc : Heikki Vatiainen
> > ; opsawg  Objet :
> Re:
> > [OPSAWG]Re: draft-ietf-opsawg-tacacs-tls13: Debugging
> > TACACS+ over TLS
> >
> >
> > On Nov 26, 2024, at 7:27 AM, mohamed.boucad...@orange.com
> wrote:
> > > I'm afraid that we need to handle this globally (e.g., in UTA
> > WG), not for every application.
> >
> >   I agree.
> >
> >   I spoke with Eric Vyncke in Dublin, and explained that while
> RFC
> > 9325 is good, RADIUS and TACACS+ were having similar issues
> with TLS.
> > i.e.. The TLS RFCs largely describe what TLS does, but are
> somewhat
> > thin on how applications can use TLS.  The RADEXT WG has spent
> > substantial time digging into a number of issues, and updating
> drafts
> > with what we've found.
> >
> >   His suggestion was the same as yours: This needs to be done
> in UTA.
> > He also pointed out that as someone involved in RADEXT, and as
> > co-chair of UTA, I was the ideal person to write this document.
> >
> >   The good news is that much of the necessary text is already
> in the
> > RADEXT drafts, so perhaps the work isn't as large as it could
> have
> > been,
> >
> >   I'll try to find some time.
> >
> >   Alan DeKok.


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.
___
OPSAWG mailing list -- opsawg@ietf.org
To unsubscribe send an email to opsawg-le...@ietf.org