Re: [OPSAWG] TACACS+ RFC: Regarding submission

["Black, David" <[e-mail]>]

Hi Doug,

> 2: Originally we were going to use a separate port, however, when the start-TLS mechanism was proposed this seemed more elegant, it seemed to be
> the precedent for other recent protocols that had TLS added (SMTP etc) and of course, meant that a new port did not need to be allocated. So the use of
> a separate port was deprecated because we believe that reusing the current was the "right thing to do".

In other words, use of a separate port for TACACS+ over TLS has already been considered, and the result is that
a single port with start-TLS seems like the "right thing to do" for TACACS+, which sounds like a fine conclusion to me.

> 3a: Registering the AV-Pairs with IANA: Certainly, makes sense. Just a sanity check though: it would be good to know the implications of doing this.
> In current deployments, many vendors freely use their own av-pairs. Would registering these with IANA this impose an overhead that we do not
> currently have, in vendors adding attributes?.

How do current deployments avoid collisions between av-pairs defined by different vendors, specifically two vendors using the same attribute name for different attributes?  This can be avoided by using IANA registration as a low-overhead collision-avoidance mechanism.  In RFC 5226 this is about the difference between "Private Use" (collisions possible) and "First Come First Served" (IANA registration prevents collisions) in Section 4.1:
      https://tools.ietf.org/html/rfc5226#section-4.1

> 3b: Adding protocol constants to IANA: Certainly. However, most of these enumerations are part of the protocol and should really be locked (such as status,
>  Authentication action etc) in order to achieve reasonable levels of interoperability. By registering with IANA, can we still provide sufficient control to ensure
> that they are not adversely adjusted?

Yes, by specifying a suitably restrictive allocation policy.  RFC 6580 is a worked example where analogous constants from another protocol were put into IANA registries - the suitably restrictive "magic words" used there are:
Allocation Policy: Standards Action [RFC5226]

That allocation policy requires a standards-track RFC to make additions or changes, see Section 4.1 of RFC5226.

Thanks,
--David

From: Douglas Gash (dcmgash) [mailto:[e-mail]]
Sent: Monday, June 15, 2015 12:44 PM
To: Black, David; [e-mail]
Cc: Thorsten Dahm; Andrej Ota
Subject: Re: [OPSAWG] TACACS+ RFC: Regarding submission

Hi David,

Many thanks for the review and the insightful comments!

1: Thanks, yes, we will add the security considerations section as suggested.
2: Originally we were going to use a separate port, however, when the start-TLS mechanism was proposed this seemed more elegant, it seemed to be the precedent for other recent protocols that had TLS added (SMTP etc) and of course, meant that a new port did not need to be allocated. So the use of a separate port was deprecated because we believe that reusing the current was the "right thing to do". This is exactly the right place to find out if we were correct! If there is any thought that we proceeded down the wrong path here, we will, of course, be happy to change.
3a: Registering the AV-Pairs with IANA: Certainly, makes sense. Just a sanity check though: it would be good to know the implications of doing this. In current deployments, many vendors freely use their own av-pairs. Would registering these with IANA this impose an overhead that we do not currently have, in vendors adding attributes?.
3b: Adding protocol constants to IANA: Certainly. However, most of these enumerations are part of the protocol and should really be locked (such as status, Authentication action etc) in order to achieve reasonable levels of interoperability. By registering with IANA, can we still provide sufficient control to ensure that they are not adversely adjusted?
4: Thanks yes, we will add/correct a reference to the original draft.

Many thanks!

(The doc authors collective).

From: <Black>, David <[e-mail]<mailto:[e-mail]>>
Date: Friday, 12 June 2015 20:37
To: Douglas Gash <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: RE: [OPSAWG] TACACS+ RFC: Regarding submission

This generally seems like a good idea.

> However, included in the document is a new feature that we propose for discussion: Support for TLS using
> a new packet type allows the TACACS protocol to upgrade itself to a TLS tunnel. Please see section 3.6.2.
> This is added in a way that is intended not to interfere with any current implementations of TACACS+.

I think this feature is a good addition.  The draft currently lacks a Security Considerations section - that would a good place to say that TLS is preferable to legacy TACACS encryption (3.6.1) *when there is a choice* and discuss the circumstances under which there is no choice (e.g., interoperability required with deployed systems).

Please consider the design alternative of using a separate port for TACACS-over-TLS (NB: "consider" *not* "change to").  There is no protocol-independent IETF consensus on whether separate ports should be used for secure and insecure variants of the same protocol, see section 7.4 of draft-ietf-tsvwg-port-use, currently at the RFC Editor:
https://tools.ietf.org/html/draft-ietf-tsvwg-port-use-11#section-7.4

Hence, using a single port is fine, and is preferable in the absence of other considerations, as one less port is used.

I also see no IANA Considerations section - at a minimum, the AVPs in Section 7 should be put into a new IANA registry, as that's an intended area of extensibility.  I also see a number of lists of values in Sections 4-6 that may also benefit from being put into IANA registries if there's a reasonable possibility of future additions.

> TACACS+ is a protocol widely deployed, based upon a draft specification that Cisco submitted in 1998, but never completed to RFC status.
> The original draft has been tidied and lightly enhanced and resubmitted, with the intent to finally get it published as a standard.

Some sort of reference to that original draft should be provided.  The current [TheDraft] reference to RFC 2200 for this purpose doesn't get that job done.  It looks like that expired draft is draft-grant-tacacs-02.  Is RFC 1492 also relevant?

Thanks,
--David

From: OPSAWG [mailto:[e-mail]] On Behalf Of Benoit Claise
Sent: Friday, June 12, 2015 8:52 AM
To: Douglas Gash (dcmgash); [e-mail]<mailto:[e-mail]>
Subject: Re: [OPSAWG] TACACS+ RFC: Regarding submission

For information, the draft is at: http://datatracker.ietf.org/doc/draft-dahm-opsawg-tacacs/

Regards, B;
Please note the following concerning the document content:

The majority of the document is a cleaned and tidied refresh of the original draft.
However, included in the document is a new feature that we propose for discussion: Support for TLS using a new packet type allows the TACACS protocol to upgrade itself to a TLS tunnel. Please see section 3.6.2. This is added in a way that is intended not to interfere with any current implementations of TACACS+.

Also, a note in relation to TACACS+ and RADIUS. Although the protocols were probably about equivalent in 1998, the addition of EAP and other enhancements mean that RADIUS is the default protocol for Network Access. By reviving the TACACS+ draft we have no intention of influencing this status quo. However, TACACS+ does have a continued and widely deployed use case for Device Administration. This is due to its strict separation of authorisation from authentication which allows per-command authorisation, and its TCP transport for allowing effective accounting. It is to support this use case that TACACS+ is proposed for progress to a standard, and informed the thoughts for the potential selection of a workgroup, however if this selection is misguided, please let us know.

Many thanks,

Regards,

Doug.



From: Douglas Gash <[e-mail]<mailto:[e-mail]>>
Date: Friday, 12 June 2015 08:23
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Cc: Thorsten Dahm <[e-mail]<mailto:[e-mail]>>, Andrej Ota <[e-mail]<mailto:[e-mail]>>, "Michael Keenan (mikeenan)" <[e-mail]<mailto:[e-mail]>>, "Satyanarayana Danda (sdanda)" <[e-mail]<mailto:[e-mail]>>, "John Delaney (jodelane)" <[e-mail]<mailto:[e-mail]>>
Subject: TACACS+ RFC

Hi,

TACACS+ is a protocol widely deployed, based upon a draft specification that Cisco submitted in 1998, but never completed to RFC status. The original draft has been tidied and lightly enhanced and resubmitted, with the intent to finally get it published as a standard.

The best fit that we could see was for the opsawg.

Many thanks,

Regards,

Doug.





_______________________________________________

OPSAWG mailing list

[e-mail]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/opsawg