Re: [OPSAWG] APPEAL: re AAA protocols and IETF consensus

[Alan DeKok <[e-mail]>]

On Feb 11, 2016, at 12:46 PM, Christopher Morrow <[e-mail]> wrote:
> 2989 is titled: "Criteria for Evaluating AAA Protocols for Network Access"
> 
> 2989 is explicitly not about 'device management' or 'device
> administration' access management (AAA).
> tacacs+ is explicitly about 'device management' or 'device
> administration' access management (AAA).

  The TACACS draft is silent on device management.  The only discussion in the draft of functionality is AAA.

  For you, the AAA RFCs I mentioned don't apply to a self-described AAA document.  Because the document really (wink wink) applies to device management.  Which it doesn't talk about.

  i.e. A isn't the same as B because A is really the same as C, even though A claims to be the same as B.

  This is logic so twisted as to become farcical. 

> again, not applicable to 'device management' / 'device administration'
> ... so not applicable to this discussion, at all.

  Then you should be in favour of not standardizing the TACACS+ document, because it doesn't talk about device management either.

>>  Standardizing a new AAA protocol without IETF-wide discussion means we're ignoring the requirements of RFC 2989, and discarding the results shown in RFC 3127.
>> 
> 
> it doesn't seem like 'IETF-wide discussion' is being missed at all, actually.

  Forgive me if I'm missing a wider CC list.  Are the people who wrote RFC 2989 and RFC 3127 involved in this discussion?  No?  Then a wider IETF discussion is being missed.

> perhaps, but you seem to have content questions, did you make these
> comments to the authors?

  I think dealing with larger issues is a higher priority than editorial comments.

>>  The TACACS+ functionality therefore *explicitly* overlaps 100% with RADIUS.  It is explicitly *not* "device authorization".  It is uniformly inferior to RADIUS in functionality and capability.  It meets none of the requirements set out in RFC 2989, and wasn't even considered in RFC 3127
> 
> because 2989 and 3127 are not about the problem tac+ solves.

  And neither is the TACACS+ document.

> For network operations the meaning of AAA is different than that used
> for 'dialup users' (or equivalent as the technology advances).
> 
> o Authorizing users of your network access to the network is different
> than authorizing administration/management of the devices which make
> the network.
> 
> o Accounting for the device administration activities is not the same
> acocunting for bits/time spent on a customer
> 
> o Authenticating a device administrator is likely very different from
> authenticating a user of the network

  Remind me again where the TACACS+ document discusses that?

> I think you mean to rephrase and aim this comment to the editors... so
> they can add a note about it in the draft. I do see discussion of
> authorization and why it's important/used in the original
> grant-tacacs-02 draft, and in the draft-dahm version 02 there's this:
> 
> https://tools.ietf.org/html/draft-dahm-opsawg-tacacs-01#section-5
> 
> this seems to have some level of detail and useful information about
> the authorization process/work/packets.

  Which is a vague discussion of "authorization".  It misses "device management" entirely.

> i don't know that 'two decades' is particularly important, much has
> changed over the last 20 yrs in the IETF and the Internet and in stuff
> provided by vendors/etc. Making device administration better and more
> secure over time is a win for operations, networks and users.

  While I agree with that, there were many opportunities over the last 20 years to standardize device management in the IETF.  The vendors refused.  Because (as I've said repeatedly), they saw benefits in avoiding the standards process.

  Now that they're getting bitten by inter-operability problems, *oops*, it's time get a rubber stamp on the protocol.

  I welcome publishing the document as an information draft.  I see no reason why it should be an IETF standard.  And so far, I haven't seen a convincing argument from anyone else.  The arguments in favour amount to:

- just 'cause

- it's widely used

- it's not an AAA protocol, even though it's explicitly an AAA protocol

  Alan DeKok.