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

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

Hi All,

We¹re preparing the next revision. Regarding attribute value encoding,
we¹re proposing to add the following, then to assign a type to each
attribute. As always with T+, the issue is getting the right balance in
adding some order without changing too much the draft spec.

Proposed content is as below, please share any views:




7.  Attribute-Value Pairs

   TACACS+ is intended to be an extensible protocol.  The attributes
   used in Authorization and Accounting are not limited by this
   document.  Some attributes are defined below for common use cases,
   clients MUST use these attributes when supporting the corresponding
   use cases.

7.1.  Value Encoding

   All attribute values are encoded as printable US-ASCII strings.  The
   following type representations SHOULD be followed

   Numeric

   All numeric values in an attribute-value string are provided as
   decimal printable US-ASCII numbers, unless otherwise stated.

   Boolean

   All boolean attributes are encoded with values "true" or "false".

   IP-Address

   It is recommended that hosts be specified as a IP address so as to
   avoid any ambiguities.  ASCII numeric IPV4 address are specified as
   octets separated by dots ('.'), IPV6 address text representation
   defined in RFC 4291.

   Date Time

   Absolute date/times are specified in seconds since the epoch, 12:00am
   Jan 1 1970.  The timezone MUST be UTC unless a timezone attribute is
   specified. 

   String

   Many values have no specific type representation and so are
   interpreted as plain strings.

   Empty Values

   Attributes may be submitted with no value, in which case they consist
   of the name and the mandatory or optional separator.  For example,
   the attribute "cmd" which has no value is transmitted as a string of
   four characters "cmd="

7.2.  Authorization Attributes

   service (String)

   The primary service.  Specifying a service attribute indicates that
   this is a request for authorization or accounting of that service.
   For example: "shell", "tty-server", "connection", "system" and
   "firewall".  This attribute MUST always be included.

   protocol (String)

   the ptotocol field may be used to indicate a subset of a service.

   cmd-arg (String)

   an argument to a shell (exec) command.  This indicates an argument
   for the shell command that is to be run.  Multiple cmd-arg attributes
   may be specified, and they are order dependent.

   acl (Numeric)

   printable US-ASCII number representing a connection access list.
   Applicable only to session-based shell authorization.


Š etc

On 21/05/2017 21:34, "t.petch" <[e-mail]> wrote:

>----- Original Message -----
>Sent: Friday, May 19, 2017 7:06 PM
>
>Isn't this handled by RFC 20?
>
><tp>
>Eliot
>
>RFC20, AFACT, does not define Boolean, or Numeric or Printable (albeit
>something which the current I-D does not currently use) while its
>definition of 'text' (which the I-D does use) is based on starting with
>STX so IMHO, no.
>
>RFC20 is just a list of 128 characters with a numeric code.  Every other
>protocol specification I can think of places restrictions thereon; DC3
>in a username, anyone?
>
>RFC4234 is to me a good example of an RFC that starts with RFC20 (or the
>equivalent thereof) and produces something more usable.
>
>Tom Petch
>
>On 5/19/17 7:51 PM, Douglas Gash (dcmgash) wrote:
>>
>> 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.
>>>
>> _______________________________________________
>> OPSAWG mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/opsawg
>>
>
>
>