Subject: Re: [OPSAWG] OPSAWG Digest, Vol 107, Issue 11

From: "Douglas Gash (dcmgash)" <[email-masked]>
Date: Fri, 29 Apr 2016 05:19:15 +0000

Many thanks Alan, Stefan, Joe and Joel for the detailed review and useful
feedback,

Very much appreciated!

On 22/04/2016 20:00, "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:  TACACS+ informational document. (Alan DeKok)
>   2. Re:  TACACS+ informational document. (Stefan Winter)
>   3. Re:  TACACS+ informational document. (Alan DeKok)
>   4. Re:  TACACS+ informational document. (Joel Jaeggli)
>   5.  opsawg-capwap-alt-tunnel (Mahesh Govind)
>   6. Re:  I-D Action: draft-ietf-opsawg-tacacs-02.txt (Joe Clarke)
>
>
>----------------------------------------------------------------------
>
>Message: 1
>Date: Thu, 21 Apr 2016 22:06:25 -0400
>From: Alan DeKok <[email-masked]>
>To: Warren Kumari <[email-masked]>
>Cc: "[email-masked]" <[email-masked]>
>Subject: Re: [OPSAWG] TACACS+ informational document.
>Message-ID: <[email-masked]>
>Content-Type: text/plain; charset=us-ascii
>
>  More comments...
>
>4.4.  Description of Authentication Process
>
>   Authentications are classified by the action, authen_type and service
>   fields in the START packet of the authentication Session.  The user,
>   priv_lvl, service, port and rem_addr in the START packet are all
>   provided to help identify the conditions on the client
>
>  What is meant by "conditions on the client"?  It would be best to
>describe what those fields mean instead.
>
>  ... The information necessary to transact the authentication is passed
>...
>
>  What is "information necessary to transact the authentication"?  This
>sounds unclear to me.
>
>  ...  A set of standard authentication classifications is defined in this
>   document.  
>
>  What is meant by "authentication classifications" ?  It's not clear
>from the context or the rest of the document.  Perhaps it means
>"authentication protocols" ?  i.e. one exchange is done for PAP, another
>for MS-CHAP, another for OTP, etc.
>
>  ... When the REPLY status equals TAC_PLUS_AUTHEN_STATUS_GETDATA,
>   TAC_PLUS_AUTHEN_STATUS_GETUSER or TAC_PLUS_AUTHEN_STATUS_GETPASS,
>   then authentication continues and the server_msg may be used by the
>   client to prompt the user for more information.
>
>  "may be used"?  What happens when the client doesn't use server_msg to
>prompt the user?
>
>   ... All three cause the same action to be performed, but in the case of
>   TAC_PLUS_AUTHEN_STATUS_GETUSER, the client can know that the
>   information that the user responds with is a username, and for
>   TAC_PLUS_AUTHEN_STATUS_GETPASS, that the user response represents a
>   password.
>
>  I'm wary of statements such as "the client can know..."   Is that a
>philosophical statement?
>
>  It's generally best to describe actions instead of knowledge.  e..g.
>"for prompts using TAC_PLUS_AUTHEN_STATUS_GETUSER, the users response is
>interpreted by the client as a username, for use in subsequent exchanges".
>
>  ... TAC_PLUS_AUTHEN_STATUS_GETPASS, that the user response represents a
>   password.
>
>  Similar comments apply here.
>
>   ... TAC_PLUS_AUTHEN_STATUS_GETDATA is the generic request for
>   more information.
>
>  And what happens then with the data?  When is this message used?
>
>4.4.1.  Version Behaviour
>
>   ... in the table below:
>
>          LOGIN    CHPASS   SENDAUTH
>   ASCII      v0         v0       NA
>   PAP        v1        NA       v1
>   CHAP       v1        NA       v1
>   MS-CHAP    v1        NA       v1
>
>
>  What does "NA" mean?  I suspect I know, but it's good to be explicit
>instead of assuming that the reader knows the authors intent.
>
>  ... The removal of SENDPASS
>   was prompted by security concerns, and is no longer considered part
>   of the TACACS+ protocol.
>
>  It may be worth considering the removal of all documentation of
>SENDPASS.  If it's not just deprecated by removed entirely, then it
>should probably be just removed entirely.
>
>  4.4.2.  Common Authentication Flows
>
>   This section describes the authentication flows that should be
>   supported.
>
>  What is meant by "should be supported"?  Is this an RFC 2119 statement?
> Or are these examples of authentication flows which are in common use,
>and that all clients && servers are expected to support?
>
>   ... A PAP authentication only consists of a username and password
>   RFC 1334 [RFC1334] .
>
>  I think referencing a later RFC is preferable.
>
>  (chap)
>
>  ...   The length of the challenge value can be determined from the
>length
>   of the data field minus the length of the id (always 1 octet) and the
>   length of the response field (always 16 octets).
>
>  This would seem to impose limits on the "date len" field.  It would be
>good to state these explicitly.
>
>  Also, to indicate that the challenges MUST have a minimal length, which
>should probably be no less than 8, though 16 is suggested.  The
>alternative is to allow zero-length challenges, which is not good.
>
>  And how are the challenge, ID, and response fields packed into the data
>field?  i.e. in what order are they packed?  ASCII art would be *very*
>helpful here. 
>
>  Similar comments apply for MS-CHAPv1 and MS-CHAPv2 authentication.
>
> 4.4.3
>
>  ... When the status equals TAC_PLUS_AUTHEN_STATUS_FOLLOW the packet
>   indicates that the TACACS+ server requests that authentication should
>   be performed with an alternate server.  The data field MUST contain
>   ASCII text describing one or more servers.  A server description
>   appears like this:
>
>   [@<protocol>@]<host>>[@<key>]
>
>  Examples would help here.  The above text isn't ABNF, or any other
>machine-readable definition of a text string.
>
>  Perhaps the text could be updated to say that "@" is a delimiter. for
>text strings:
>
>0 @ = host
>1 @ = host@key
>2 @ = @protocol@host
>3 @ = @protocol@host@key
>
> ...  If a key is supplied, the client MAY use the key in order to
>   authenticate to that host.  If more than one host is specified, they
>   MUST be separated by an ASCII Carriage Return (0x0D).
>
>  Some questions here.  What happens if the client doesn't want to use
>that key?  What happens if the client is pre-provisioned with a different
>key than what is supplied here?  If there are multiple hosts, does the
>client use the supplied key for all of them?  What if the client has a
>disparate set of keys for the list of hosts?
>
> ...  This packet is
>   only currently intended for PPP authentication when multiple
>   authentication mechanisms are available and can be negotiated between
>   the client and the remote peer.  This also requires future PPP
>   authentication extensions which have not yet been passed through the
>   IETF.
>
>  Are users performing device administration over PPP?  If that isn't the
>99% case, then I suggest re-wording the paragraph.
>
>  Also, updating it to clarify what it means for "future PPP extensions".
> Perhaps just removing that sentence would be best.
>
>5.  Authorization
>
>   ...  The authorization REQUEST message contains a fixed set of fields
>that
>   describe the authenticity of the user or process,
>
>  What is "authenticity" of a user?
>
> ...  priv_lvl
>
>   This field matches the priv_lvl field in authentication request a
>
>  What does this statement mean?  Does the field (length and value) have
>to be identical to the field in the authentication request?  If not, why
>not, and what happens?  If so, it would be better to just say that it
>MUST be identical.  Similar comments apply for the other fields.  "match"
>is a word which should be used in the context of "A must match B",
>instead of "is used for matching".  The first is concrete and
>implementable.  The second is more philosophical than protocol oriented.
>
>  ...  Attribute-value strings are not NULL terminated, rather their
>length
>   value indicates their end.  The maximum length of an attribute-value
>   string is 255 characters.
>
>  Are zero-length strings allowed?  I presume not, but it would be good
>to say so.
>
>7.  Attribute-Value Pairs
>
>  ... A value of NULL means an attribute with a zero length string for its
>   value i.e. cmd=NULL is actually transmitted as the string of 4
>   characters "cmd=".
>
>  That seems contradictory.. NULL is encoded by not encoding it..
>Perhaps the text could instead say:
>
>   Attributes which have no value are transmitted as the attribute name,
>followed by the mandatory or optional flag.  The value is elided.  For
>example, the attribute "cmd" which has no value is transmitted as a
>string of 4 characters "cmd="
>
>  ... acl
>
>   US-ASCII number representing a connection access list.  Used only
>   when service=shell and cmd=NULL
>
>  I would suggest eliding the NULL here, too.  The temptation for naive
>implementors would be to encode an actual string "NULL".
>
>  
>  There should be a separate "Security Considerations" section as Section
>9.  It should explain all of the issues with the protocol, such as the
>use of "encryption", etc.
>
>  Alan DeKok.
>
>
>
>------------------------------
>
>Message: 2
>Date: Fri, 22 Apr 2016 14:13:41 +0200
>From: Stefan Winter <[email-masked]>
>To: "[email-masked]" <[email-masked]>
>Subject: Re: [OPSAWG] TACACS+ informational document.
>Message-ID: <[email-masked]>
>Content-Type: text/plain; charset=utf-8
>
>Hi,
>
>the draft states:
>
> user
>
>   The username.  It is encoded in [UTF-8].  It is optional in this
>   packet, depending upon the class of authentication.
>
>The old expired draft from 1997 states:
>
>user
>
>   The username. It is optional in this packet.
>
>
>Somehow, an explicit encoding requirement made it into the new draft. It's
>good to be explicit when designing a protocol; but when it comes
>to documenting deployed reality it's important to be sure that
>this really *is* the deployed reality.
>
>Are you sure / how sure are you that deployed reality agrees with this
>change of wording?
>
>Greetings,
>
>Stefan Winter
>
>Am 20.04.2016 um 21:49 schrieb Warren Kumari:
>> Hi there all,
>>
>> The authors of draft-ietf-opsawg-tacacs have updated the document and
>> would like some review.
>>
>> As a reminder, this document is supposed to describe how TACACS
>> currently works.
>> We will then publish a new document which improves the security of
>>TACACS.
>>
>> I'd really appreciate it if people could review the current document
>> (Link for easy
>> clicking: https://datatracker.ietf.org/doc/draft-ietf-opsawg-tacacs/)
>> and provide feedback to the list by Friday April 29th.
>>
>> W
>
>
>
>------------------------------
>
>Message: 3
>Date: Fri, 22 Apr 2016 08:38:43 -0400
>From: Alan DeKok <[email-masked]>
>To: Warren Kumari <[email-masked]>
>Cc: "[email-masked]" <[email-masked]>
>Subject: Re: [OPSAWG] TACACS+ informational document.
>Message-ID: <[email-masked]>
>Content-Type: text/plain; charset=us-ascii
>
>  A short summary:
>
>- many fields are named but not defined
>
>- structures with multiple fields are described, but field order is not
>defined
>
>- terms are used inconsistently
>
>- the document is silent on critical points
>
>  - how do user logins map to TCP connections?  1-1?  1-N?  N-M?
>
>  - can the same session_id be used in multiple TCP connections?
>
>- the general tone seems philosophical: systems "know" things, not
>prescriptive: systems "do" things.
>
>- edge cases are not discussed
>
> - what happens with zero-length fields?
>
>- common use-cases aren't described (e.g. inter-site use of the protocol)
>
>- the security considerations section is minimal
>
>  - how do the edge cases affect security?
>
>  - is the TCP connection closed when the key is found to be wrong?  If
>not, why not?
>
>  - what are best practice recommendations for deployment?
>
>  - what impact does inter-site deployment have on security?
>
>
>  As an implementor, I would have to guess at large portions of the
>protocol, or I would have to read the source to existing implementations.
> The draft as is stands today can get me ~90% of the way to implementing
>the protocol, but critical portions are not present.
>
>  Alan DeKok.
>
>
>
>------------------------------
>
>Message: 4
>Date: Fri, 22 Apr 2016 08:41:30 -0700
>From: Joel Jaeggli <[email-masked]>
>To: Alan DeKok <[email-masked]>
>Cc: "[email-masked]" <[email-masked]>
>Subject: Re: [OPSAWG] TACACS+ informational document.
>Message-ID: <[email-masked]>
>Content-Type: text/plain;	charset=us-ascii
>
>Thanks, 
>
>This is useful feedback.
>
>> On Apr 22, 2016, at 05:38, Alan DeKok <[email-masked]> wrote:
>> 
>>  A short summary:
>> 
>> - many fields are named but not defined
>> 
>> - structures with multiple fields are described, but field order is not
>>defined
>> 
>> - terms are used inconsistently
>> 
>> - the document is silent on critical points
>> 
>>  - how do user logins map to TCP connections?  1-1?  1-N?  N-M?
>> 
>>  - can the same session_id be used in multiple TCP connections?
>> 
>> - the general tone seems philosophical: systems "know" things, not
>>prescriptive: systems "do" things.
>> 
>> - edge cases are not discussed
>> 
>> - what happens with zero-length fields?
>> 
>> - common use-cases aren't described (e.g. inter-site use of the
>>protocol)
>> 
>> - the security considerations section is minimal
>> 
>>  - how do the edge cases affect security?
>> 
>>  - is the TCP connection closed when the key is found to be wrong?  If
>>not, why not?
>> 
>>  - what are best practice recommendations for deployment?
>> 
>>  - what impact does inter-site deployment have on security?
>> 
>> 
>>  As an implementor, I would have to guess at large portions of the
>>protocol, or I would have to read the source to existing
>>implementations.  The draft as is stands today can get me ~90% of the
>>way to implementing the protocol, but critical portions are not present.
>> 
>>  Alan DeKok.
>> 
>> _______________________________________________
>> OPSAWG mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/opsawg
>> 
>
>
>
>------------------------------
>
>Message: 5
>Date: Fri, 22 Apr 2016 23:18:30 +0530
>From: Mahesh Govind <[email-masked]>
>To: [email-masked]
>Subject: [OPSAWG] opsawg-capwap-alt-tunnel
>Message-ID:
>	<[email-masked]>
>Content-Type: text/plain; charset="utf-8"
>
>Hi,
>
>Could you please let me know whether any one has implemented the draft (
>opsawg-capwap-alt-tunnel
><https://tools.ietf.org/wg/opsawg/draft-ietf-opsawg-capwap-alt-tunnel/>)
>
>regards
>Mahesh
>-------------- next part --------------
>An HTML attachment was scrubbed...
>URL: 
><https://mailarchive.ietf.org/arch/browse/opsawg/attachments/20160422/1a48
>b6f0/attachment.html>
>
>------------------------------
>
>Message: 6
>Date: Fri, 22 Apr 2016 14:43:51 -0400
>From: Joe Clarke <[email-masked]>
>Cc: [email-masked]
>Subject: Re: [OPSAWG] I-D Action: draft-ietf-opsawg-tacacs-02.txt
>Message-ID: <[email-masked]>
>Content-Type: text/plain; charset=windows-1252; format=flowed
>
>I've done a quick read-through of the draft, and I have a few comments.
>
>* Assuming someone is completely unfamiliar with T+ and they came across
>this draft, they might assume "TACACS" stood for something, but it is
>not expanded.  Since this draft describes the protocol, I think it would
>be good to expand the acronym in the intro paragraph.
>
>* There are terminology spread throughout the draft (e.g., MD5,
>'TheDraft', session, etc.).  I've seen such things summarized early on
>in a glossary in other long drafts.  It might make it easier for a
>reader to refer to if that was done here as well.
>
>* There is a lot of use of NULL in this document where you either mean
>NUL byte termination or an empty field.  It would be helpful to clarify
>the usage where you mean a NUL ASCII byte or a field with a zero length
>value.
>
>* In Section 4.1, the username is stated to be encoded in UTF-8.  This
>is not the case in the _current_ implementation of the protocol.  A code
>inspection of at least the tac_plus4 module shows this is as US-ASCII as
>some of the other fields.
>
>* In Section 4.1 as well, the various AUTHEN_SVC types are defined, but
>only ENABLE (and NONE to some extent) is really described.  It would be
>useful to describe the others as well.
>
>* In Section 4.2, the "data" field is mentioned and says it will be
>described in more detail per authen_type below. Since the START, REPLY,
>and CONTINUE packets each have a "data" field, and they're respective
>sections all point to details "below," it's hard to discern what field
>is being described.  While I was able to figure out what I'd see in
>various START and CONTINUE packets, I didn't see much on what I'd see in
>the REPLY.  For example, where can I expect to see custom authn prompts
>pushed?
>
>* In Section 5.1, you define TAC_PLUS_AUTHEN_METH_LINE as a "fixed
>password associated with the line used to gain access."  I don't think
>it's clear what a "line" is.  It might be better to say "terminal line"
>or "terminal port."
>
>That's it for now.
>
>Joe
>
>On 4/12/16 09:41, [email-masked] wrote:
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>>directories.
>> This draft is a work item of the Operations and Management Area Working
>>Group of the IETF.
>>
>>         Title           : The TACACS+ Protocol
>>         Authors         : Thorsten Dahm
>>                           Andrej Ota
>>                           Douglas C. Medway Gash
>>                           David Carrel
>>                           Lol Grant
>> 	Filename        : draft-ietf-opsawg-tacacs-02.txt
>> 	Pages           : 35
>> 	Date            : 2016-04-11
>>
>> Abstract:
>>    TACACS+ provides Device Administration for routers, network access
>>    servers and other networked computing devices via one or more
>>    centralized servers.  This document describes the protocol that is
>>    used by TACACS+.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-opsawg-tacacs/
>>
>> There's also a htmlized version available at:
>> https://tools.ietf.org/html/draft-ietf-opsawg-tacacs-02
>>
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-tacacs-02
>>
>>
>> Please note that it may take a couple of minutes from the time of
>>submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> _______________________________________________
>> OPSAWG mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/opsawg
>>
>
>
>
>------------------------------
>
>Subject: Digest Footer
>
>_______________________________________________
>OPSAWG mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/opsawg
>
>
>------------------------------
>
>End of OPSAWG Digest, Vol 107, Issue 11
>***************************************