Re-,
Deal. I updated the module accordingly. I also sent a note right now to the
authors of T+TLS to cover this in this base spec.
For the list point, we used to have multiple addresses under the same instance
but removed it because you convinced me that this adds more complexity as we
can define those as separate server instances (and that redundancy group can be
handled at the server instance levels):
OLD:
+--rw remote-address* [address]
| +--rw address inet:ip-address
| +--rw port-number? inet:port-number
Are you referring to this or something else? Thanks.
Cheers,
Med
De : Joe Clarke (jclarke) <[email protected]>
Envoyé : jeudi 12 décembre 2024 15:30
À : BOUCADAIR Mohamed INNOV/NET <[email protected]>; [email protected]
Objet : Re: CALL FOR ADOPTION: A YANG Model for Terminal Access Controller
Access-Control System Plus (TACACS+) over TLS 1.3
As a contributor, I agree. I think from a security point of view a fallback to
an insecure state should be strongly discouraged.
Also, you mentioned you were going to address the list thing in the module when
it comes to how T+ servers are defined. I didn't see that in this new draft.
Joe
From: [email protected]<mailto:[email protected]>
<[email protected]<mailto:[email protected]>>
Date: Thursday, December 12, 2024 at 09:11
To: Joe Clarke (jclarke) <[email protected]<mailto:[email protected]>>,
[email protected]<mailto:[email protected]>
<[email protected]<mailto:[email protected]>>
Subject: RE: CALL FOR ADOPTION: A YANG Model for Terminal Access Controller
Access-Control System Plus (TACACS+) over TLS 1.3
Hi Joe,
You are right. The reason I had this is that we don't have explicit text that
fallback when TLS fails is forbidden.
We do have in the base spec the following, which recommends against (but still
that's not forbidden):
It is NOT RECOMMENDED that TLS TACACS+ servers and Non-TLS TACACS+
servers be deployed on the same host, for reasons discussed in
Section 5.3. Non-TLS connections would be better served by deploying
the required Non-TLS TACACS+ servers on separate hosts.
If we add an explicit statement in the base T+TLS spec that fall back is not
allowed, I think that we can remove tls/non-tls stats, which is simpler.
Cheers,
Med
De : Joe Clarke (jclarke) <[email protected]<mailto:[email protected]>>
Envoyé : jeudi 12 décembre 2024 14:47
À : BOUCADAIR Mohamed INNOV/NET
<[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]>
Objet : Re: CALL FOR ADOPTION: A YANG Model for Terminal Access Controller
Access-Control System Plus (TACACS+) over TLS 1.3
Thanks, Med. Looks good, but I wonder why we need a set of TLS and non-TLS
statistics? Those stats are per-server, so if the server is TLS, then the
extra stats will be there. If not, then you have just the base stats.
Joe
From: [email protected]<mailto:[email protected]>
<[email protected]<mailto:[email protected]>>
Date: Wednesday, December 11, 2024 at 07:41
To: Joe Clarke (jclarke) <[email protected]<mailto:[email protected]>>,
[email protected]<mailto:[email protected]>
<[email protected]<mailto:[email protected]>>
Subject: RE: CALL FOR ADOPTION: A YANG Model for Terminal Access Controller
Access-Control System Plus (TACACS+) over TLS 1.3
Hi Joe,
Please find a proposal to address both SNI/stats comments discussed below:
https://author-tools.ietf.org/api/iddiff?doc_1=draft-ietf-opsawg-secure-tacacs-yang&url_2=https://boucadair.github.io/secure-tacacs-yang/draft-ietf-opsawg-secure-tacacs-yang.txt
Your feedback is welcome. Thanks.
Cheers,
Med
De : Joe Clarke (jclarke) <[email protected]<mailto:[email protected]>>
Envoyé : mercredi 23 octobre 2024 14:38
À : BOUCADAIR Mohamed INNOV/NET
<[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]>
Objet : Re: CALL FOR ADOPTION: A YANG Model for Terminal Access Controller
Access-Control System Plus (TACACS+) over TLS 1.3
Why do you define a new grouping, tcp-server-info? Why not just augment what
is in 9105? This adds complexity with minimal, if any, benefit that I see.
[Med] 9105 does not have a list. The initial intent was to cover when there are
more addresses to reach the same server identifier by the same domain-name for
redundancy and so on. We could configure two sever entries, but then all the
credentials will need to be repeated for each member of the group. Also, if
there is a procedure to fall back when an instance is not responsive, that will
be difficult to control with the separate entries. Would that makes sense?
[JMC] No, 9105 doesn't have a list of addresses to refer to a single server.
That said, in my experience I haven't needed that. I accomplish redundancy via
multiple server instances (where they sync state or have a common config
database). I don't know that having multiple addresses per instance adds a lot
of practical value vs. The added complexity and possible confusion.
Does the new domain-name leaf need to be mandatory if certs are used?
[Med] I don't think so as DNS-ID and IP-ID are allowed for identification. No?
This prompted me that a check is needed when SNI is enabled but we don't have a
knob to control SNI activation. I think we need one.
[JMC] Thanks for the confirmation. Yes, SNI would be a good thing to cover.
Finally, on operational data, should this module introduce any TLS-specific
stats in addition to those in 9105? I feel like certificate issues or PSK
problems might be useful.
[Med] Good point. Will cover this in future iterations.
[JMC] Thanks ! Last night I was thinking having stats on server vs. client
auth failures would be helpful.
Joe
____________________________________________________________________________________________________________
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.
____________________________________________________________________________________________________________
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.
____________________________________________________________________________________________________________
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 -- [email protected]
To unsubscribe send an email to [email protected]
