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:[email protected]]
Sent: Monday, June 15, 2015 12:44 PM
To: Black, David; [email protected]
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 <[email protected]<mailto:[email protected]>>
Date: Friday, 12 June 2015 20:37
To: Douglas Gash <[email protected]<mailto:[email protected]>>,
"[email protected]<mailto:[email protected]>"
<[email protected]<mailto:[email protected]>>
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:[email protected]] On Behalf Of Benoit Claise
Sent: Friday, June 12, 2015 8:52 AM
To: Douglas Gash (dcmgash); [email protected]<mailto:[email protected]>
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 <[email protected]<mailto:[email protected]>>
Date: Friday, 12 June 2015 08:23
To: "[email protected]<mailto:[email protected]>"
<[email protected]<mailto:[email protected]>>
Cc: Thorsten Dahm <[email protected]<mailto:[email protected]>>,
Andrej Ota <[email protected]<mailto:[email protected]>>, "Michael Keenan
(mikeenan)" <[email protected]<mailto:[email protected]>>, "Satyanarayana
Danda (sdanda)" <[email protected]<mailto:[email protected]>>, "John Delaney
(jodelane)" <[email protected]<mailto:[email protected]>>
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
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/opsawg
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
