Subject: Re: [OPSAWG] OPSAWG Digest, Vol 105, Issue 65

From: "Douglas Gash (dcmgash)" <[email-masked]>
Date: Thu, 11 Feb 2016 20:35:17 +0000

I believe the content isn¹t entirely vendor specific. For example, for
command authorisation, the standard authorisation packet from the document
is:

service=shell
cmd=<command name>
cmd-arg=<arg1>
cmd-arg=<arg2>
...

This level of content is specified in the document, but if the comment is
that it is insufficiently clear then I would accept that and we can raise
its visibility.

If, on the other hand you mean that the <command name> and <argN> are
vendor specific, then clearly, this is the case, but that is a feature of
a higher level in the stack than this document could specify.

On 11/02/2016 20:21, "OPSAWG on behalf of [email-masked]"
<[email-masked] on behalf of [email-masked]> wrote:

>Send OPSAWG mailing list submissions to
>	[email-masked]
>
>To subscribe or unsubscribe via the World Wide Web, visit
>	https://www.ietf.org/mailman/listinfo/opsawg
>or, via email, send a message with subject or body 'help' to
>	[email-masked]
>
>You can reach the person managing the list at
>	[email-masked]
>
>When replying, please edit your Subject line so it is more specific
>than "Re: Contents of OPSAWG digest..."
>
>
>Today's Topics:
>
>   1. Re:  Way forward? Re: Procedural issues with the TACACS+
>      document (Alan DeKok)
>
>
>----------------------------------------------------------------------
>
>Message: 1
>Date: Thu, 11 Feb 2016 15:21:03 -0500
>From: Alan DeKok <[email-masked]>
>To: Eliot Lear <[email-masked]>
>Cc: "[email-masked]" <[email-masked]>
>Subject: Re: [OPSAWG] Way forward? Re: Procedural issues with the
>	TACACS+ document
>Message-ID: <[email-masked]>
>Content-Type: text/plain; charset=us-ascii
>
>On Feb 11, 2016, at 2:36 PM, Eliot Lear <[email-masked]> wrote:
>> One has to put into perspective what was going on back then.  Many
>>different approaches were proposed to cover not only AAA but policy in
>>general, and the market was at risk of fragmentation.  There was a
>>pretty visible and dare I say heated process at the IETF that turned
>>into an attempt to align those who wanted to pursue policy with COPS and
>>COPS-PR and those who wanted to do something with RADIUS/Diameter.
>>RFC 3127 and its predecessor RFC 2989 represented hard work in the
>>context of the efforts going on at the IETF at the time.  It was a tool
>>upon which the ADs relied to organize the work of O&M at the time.
>
>  I understand.  I was involved in those discussions at the time.  As a
>less public figure than I am now, but I was still a participant.
>
>> However, in the 15 interceding years, what's become clear is that
>>RADIUS has broad applicability for a great many AAA uses; and for some
>>cases TACACS+ is appropriate.  For these purposes, such as command
>>authorization, TACACS+ is a defacto standard, no matter what the IETF
>>process says.  The nascence of this space is long past.  RFC 3127 was
>>never intended to be a constraint so far into the future but rather a
>>guide to ADs at the time as to how to proceed.
>
>  I welcome new protocols (even old ones) to solve problems that existing
>protocols don't solve.
>
>> The choice here, it seems to me, is really one of change control.  I
>>agree with you, Tom, and others who write that the IETF doesn't just
>>rubber stamp protocols.  On the other hand, changes should be made with
>>due care toward what is deployed.  I personally have faith that our
>>processes and good community involvement would provide for a good path
>>forward on this.
>> 
>> In summary, if people want a standard, I propose the following way
>>forward:
>> 
>> 1.  An applicability statement for TACACS+ that describes when TACACS+
>>is appropriate for use;
>> 2.  The proper following of working group process;
>> 3.  Appropriate and timely IPR declarations; and
>> 4.  It should be clear that the IETF has the necessary rights to effect
>>changes.
>
>  Those are all good steps.
>
>  I'd still like to know why it's necessary to have the cachet of an IETF
>standard for a protocol which is vendor-specific.  And for which the
>*functional* change control will still reside with the vendors.  And for
>which the vendors *could* have standardized it via an IETF protocol at
>any time in the past 20 years, and refused, because they saw benefits in
>bypassing the standardization process.
>
>  i.e. the contents of any device management authorization exchange are
>entirely vendor specific, and due to the way TACACS+ is being used,
>*must* remain vendor-specific.
>
>  Alan DeKok.
>
>
>
>------------------------------
>
>Subject: Digest Footer
>
>_______________________________________________
>OPSAWG mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/opsawg
>
>
>------------------------------
>
>End of OPSAWG Digest, Vol 105, Issue 65
>***************************************

---

From: "Douglas Gash (dcmgash)" <[email-masked]>
Date: Thu, 11 Feb 2016 21:14:09 +0000

On 11/02/2016 20:21, "OPSAWG on behalf of [email-masked]"
<[email-masked] on behalf of [email-masked]> wrote:

>standard for a protocol which is vendor-specific.

So the protocol itself is not intended to be vendor specific, and if you
spot any vendor specific elements, please shout them out so that we can
discard them.

>  And for which the *functional* change control will still reside with
>the vendors.

In terms of the data on top of the protocol, such as specific commands and
arguments,  then I think this is a higher level on the stack. I would
suggest that this would generally be regarded as application layer
configuration in the TACACS+ servers.

>  And for which the vendors *could* have standardized it via an IETF
>protocol at any time in the past 20 years, and refused, because they saw
>benefits in bypassing the standardization process.

I am not aware of any refusal to standardise the TACACS+ protocol. In fact
it was only a couple of years ago that I realised that TACACS+ had never
been approved as a standard by IETF, it is so pervasive that I assumed it
had been. I had it on my todo list to try to rectify that situation, and
so when some engineers from outside Cisco, who were users of the protocol
suggested moving forward with standardisation I was very happy to
contribute, and generally the response has been favourable.

>*must* remain vendor-specific.

Certainly, the content that the protocol carries must be flexible enough
to support the needs of whatever applications vendors and users need, as
requirements evolve. But we can standardise the way the commands are
encoded, and that is the purpose of the document.

Is this level of standardisation, I.e. How device application level
commands are encoded, acceptable to you, rathe than requiring we
standardise the application level commands themselves?

Thanks,

Regards,

Doug.

---

From: Alan DeKok <[email-masked]>
Date: Thu, 11 Feb 2016 17:59:38 -0500

> configuration in the TACACS+ servers.

  That is a good argument... but it means that the purpose of the protocol is little more than transporting vendor-specific data.  Which makes the protocol less relevant for standardization.

> standardise the application level commands themselves?

  It's a step.  But my concerns still remain.

  My concerns would be best addressed by pretty much re-writing the document, and changing it's focus.  Remove all of the discussion of TACACS+ as a AAA protocol.  Remove the definitions of Authentication, Authorization, and Accounting, they are well known and defined in many other places.  Make it clear that the focus of the protocol is command authorization, and nothing else.  That other functionality is deprecated, and SHOULD NOT be used.

  If that mirrors the current use-case for the protocol, these changes should be acceptable.  if the changes are not acceptable, then it's clear that the protocol is intended to compete directly with RADIUS.  In which case I wold object strenuously to the document as a standards track protocol.

  The security considerations section of the document needs to be more than a paragraph.  The non-TLS version of the TLS protocol should be deprecated.

  For" 3.6.1.  Legacy Body Encryption", the text should be changed to use the term "obfuscation".  The method described is not what would be described in the crypto community as "encryption".  IMHO, the packet encryption method should be removed entirely, and TLS transport mandated.

  Alan DeKok.

---

From: "Douglas Gash (dcmgash)" <[email-masked]>
Date: Thu, 11 Feb 2016 23:48:12 +0000

I think that your suggestions about refocussing the document to clarify
that the use case of TACACS+ is for Device Administration makes good
sense. I agree it will likely entail a significant re-work, but I don¹t
think that the author collective will shy from that. Further, I think this
input  will ultimately make it a better and more appropriate document, and
hopefully, even a standard.

I also agree with change of terminology of the legacy encryption to
obfuscation. Outright removal might be tricky, but instead casting it
strongly as a deprecated may help bridge the gap.

We may need a little time, but I think we can use this to get a good
outcome, thanks for your patient input!

Thanks,

Regards,

Doug.

On 11/02/2016 22:59, "Alan DeKok" <[email-masked]> wrote:

>  That is a good argument... but it means that the purpose of the
>protocol is little more than transporting vendor-specific data.  Which
>makes the protocol less relevant for standardization.
>
>  My concerns would be best addressed by pretty much re-writing the
>document, and changing it's focus.  Remove all of the discussion of
>TACACS+ as a AAA protocol.  Remove the definitions of Authentication,
>Authorization, and Accounting, they are well known and defined in many
>other places.  Make it clear that the focus of the protocol is command
>authorization, and nothing else.  That other functionality is deprecated,
>and SHOULD NOT be used.
>
>  If that mirrors the current use-case for the protocol, these changes
>should be acceptable.  if the changes are not acceptable, then it's clear
>that the protocol is intended to compete directly with RADIUS.  In which
>case I wold object strenuously to the document as a standards track
>protocol.
>
>  The security considerations section of the document needs to be more
>than a paragraph.  The non-TLS version of the TLS protocol should be
>deprecated.
>
>  For" 3.6.1.  Legacy Body Encryption", the text should be changed to use
>the term "obfuscation".  The method described is not what would be
>described in the crypto community as "encryption".  IMHO, the packet
>encryption method should be removed entirely, and TLS transport mandated.
>
>  Alan DeKok.
>