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 protected]" <[email protected] on behalf of [email protected]> wrote: >Send OPSAWG mailing list submissions to > [email protected] > >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 protected] > >You can reach the person managing the list at > [email protected] > >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 protected]> >To: Warren Kumari <[email protected]> >Cc: "[email protected]" <[email protected]> >Subject: Re: [OPSAWG] TACACS+ informational document. >Message-ID: <[email protected]> >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 protected]> >To: "[email protected]" <[email protected]> >Subject: Re: [OPSAWG] TACACS+ informational document. >Message-ID: <[email protected]> >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 protected]> >To: Warren Kumari <[email protected]> >Cc: "[email protected]" <[email protected]> >Subject: Re: [OPSAWG] TACACS+ informational document. >Message-ID: <[email protected]> >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 protected]> >To: Alan DeKok <[email protected]> >Cc: "[email protected]" <[email protected]> >Subject: Re: [OPSAWG] TACACS+ informational document. >Message-ID: <[email protected]> >Content-Type: text/plain; charset=us-ascii > >Thanks, > >This is useful feedback. > >> On Apr 22, 2016, at 05:38, Alan DeKok <[email protected]> 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 protected] >> https://www.ietf.org/mailman/listinfo/opsawg >> > > > >------------------------------ > >Message: 5 >Date: Fri, 22 Apr 2016 23:18:30 +0530 >From: Mahesh Govind <[email protected]> >To: [email protected] >Subject: [OPSAWG] opsawg-capwap-alt-tunnel >Message-ID: > <capw0hrpvmjr8bg2lxcnljgc3rvpv3sdqvkf+lckzbdjucot...@mail.gmail.com> >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 protected]> >Cc: [email protected] >Subject: Re: [OPSAWG] I-D Action: draft-ietf-opsawg-tacacs-02.txt >Message-ID: <[email protected]> >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 protected] 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 protected] >> https://www.ietf.org/mailman/listinfo/opsawg >> > > > >------------------------------ > >Subject: Digest Footer > >_______________________________________________ >OPSAWG mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/opsawg > > >------------------------------ > >End of OPSAWG Digest, Vol 107, Issue 11 >*************************************** _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
