Re: [OPSAWG] draft-ietf-opsawg-tacacs-06 ASCII

["Douglas Gash (dcmgash)" <[e-mail]>]

On 19/05/2017 18:11, "Alan DeKok" <[e-mail]> wrote:

>On May 19, 2017, at 6:38 AM, t.petch <[e-mail]> wrote:
>> 
>> Another fresh topic, so a slight change in the Subject:
>> 
>> I think that the use of the term ASCII needs more thought.
>
>  Speaking only as an opinionated WG member... yes.
>
>> d) in some places, I think that the term ASCII is being used too
>> loosely.  ASCII is a character set and an encoding.  If you simply say
>> US-ASCII, then you are including DC3 and FF, for example, which are
>> unlikely to be valid.  Some use US-ASCII to mean printable ASCII, some
>> to mean alphameric plus a few others such as hyphen-minus and period.
>> This needs defining.  I don't know how many different character sets you
>> have - I was surprised that '&£#' (or some such) is a valid identifier
>> in places where an equal sign is not - so this needs more work.
>
>  I agree.
Will align the ASCII references for sure, and tie down. I propose to
restrict to printable. Though, to add to complexity: it is common
practice, for example, to include newline in banners.

>
>> e) this leads into data types, which Alan raised.  Boolean is used as a
>> data type. (I have seen it as a character string of 'true'/'false' of
>> '0'/'1' with zero meaning either true or false or vice versa or as a
>> binary integer of some number of bits or ....)  As Alan implied, section
>> 7 and others are full of data types but on the one hand, what type it is
>> is usually omitted and on the other hand, the data types are not
>> defined.
>
>  The main issue with data types is that TACACS+ is a protocol based on
>printable strings.  So "data types" really means "printed versions of
>data types", which is a lot more problematic than "32-bit integer".

I agree. Will put a section in regarding at a types, specifically for
attributes (As Alan pointed out).

>
>> You need to define datatypes; from the current I-D, I do not know how
>> many there would be; probably not many.  Look for example at TLS
>> (RFC5246) or YANG (RFC6020) which nail down the datatypes, semantic and
>> encoding, before they define data structures.  This is what I think that
>> you should do, on a smaller scale.  Since YANG is being so widely
>> deployed, you would get brownie points IMO for being in line with YANG
>> wherever possible
>
>  That's good, tho there are inconsistencies.  e.g. Yang "string" doesn't
>exactly map to TACACS+ "US-ASCII thing".  Yang "boolean" is "true/false",
>while TACACS+ has used "yes/no".
>
>  We added data types to RADIUS, because it had (roughly) data types from
>day one, 32-bit integers, and all of the implementors had already agreed
>on meanings / encodings for them.  So RFC8044 was just a codification of
>existing practices, and not any change to implementations.
>
>  Then there's the additional issue of trying to define data types for a
>protocol that's entirely string based, and has 18 years of implementation
>practice.
>
>  i.e. before defining data types, it would be good to know what
>implementors have done, and then define types that match that.
>
>  However, implementors are largely silent about all possible TACACS+
>issues.  Which makes me think that the draft should name the data types,
>but be a bit vague about what they contain.

Agreed, but try to be explicit about the vagueness.


>
>> I see a need for boolean, character string/text, IPv4 address, IPv6
>> address, time interval, integer (positive ?negative).  I would like a
>> section on datatypes at the front, section 1 or 2.
>
>  I'd agree, subject to the caveats raised above.  i.e. "boolean is
>boolean, typically yes/no, but maybe also true/false, we really don't
>know..."
>
>> f) in a similar vein, you use what I take to be hexadecimal
>> representation but are inconsistent with it. I see
>> OX0D 0x0D 0x1 0x01
>> This should be consistent and is also worth defining, as a
>> representation.
>
>  I agree, subject to the same caveats.  It would also be nice to know
>what implementations do...
>
>> g) and then there is i18n, which gets an implicit mention with UTF8 but
>> harks back to d).  How much of UTF8 is allowed and where; it encompasses
>> over 65k characters these day:-(


Well, the approach we had in mind is printable US-ASCII for all fields,
apart form username and passwords, which are the hard points in
interfacing to identity provides which support. For these fields, to allow
UTF-8 on top of the byte streams.


>
>  IMHO, the draft should just mention 18n, and run away screaming. :(
>
>  As in, "we know about it, we don't know how to fix it, we don't know
>what implementations do, the fields are defined to be US-ASCII, if they
>contain anything else, that's bad."
>
>> This amounts to a lot of potential detailed change, but I would like to
>> see consensus on the approach first before edits are proposed or made.
>
>  I think this is the right approach.
>
>  Alan DeKok.
>