From mitch.raful at dimensiondata.com Tue Mar 14 22:22:56 2017 From: mitch.raful at dimensiondata.com (Mitch Raful (ITaaS)) Date: Tue, 14 Mar 2017 22:22:56 +0000 Subject: [tac_plus] md5 and tac_plus Message-ID: <14FA6FD3-5A4E-4C27-A85A-2B34DF9B2E74@itaas.dimensiondata.com> I cannot find a Python based tacacs client. I am attempting to write one on my own and can?t figure out the md5 data obfuscation. How does tac_plus handling that. Does it XOR an md5 hash, and add that hash to the session_id + key, version and sequence, and then again if needed? Thanks, Mitch Mitch Raful Sr. Network Engineer Dimension Data Cloud Business Unit 43490 Yukon Drive Ashburn, VA 21047 Office: 703-724-8862 Cell: 804-363-0731 -------------- next part -------------- An HTML attachment was scrubbed... URL: From alan.mckinnon at gmail.com Wed Mar 15 09:18:54 2017 From: alan.mckinnon at gmail.com (Alan McKinnon) Date: Wed, 15 Mar 2017 11:18:54 +0200 Subject: [tac_plus] md5 and tac_plus In-Reply-To: <14FA6FD3-5A4E-4C27-A85A-2B34DF9B2E74@itaas.dimensiondata.com> References: <14FA6FD3-5A4E-4C27-A85A-2B34DF9B2E74@itaas.dimensiondata.com> Message-ID: On 15/03/2017 00:22, Mitch Raful (ITaaS) wrote: > I cannot find a Python based tacacs client. I am attempting to write one on my own and can?t figure out the md5 data obfuscation. How does tac_plus handling that. Does it XOR an md5 hash, and add that hash to the session_id + key, version and sequence, and then again if needed? Not quite, but you are on the right track. There are 2 sources I can think of to fins the correct details: - There's an unapproved RFC out there from Cisco that despite never moving out of draft status, is still the way the tacacs protocol works. Usage of the key is in there. - read the tacacsplus code. I recall reading it once and the relevant function was easy to find. don;t have a copy of sources handy to lok for you though. -- Alan McKinnon alan.mckinnon at gmail.com From mitch.raful at dimensiondata.com Wed Mar 15 12:04:33 2017 From: mitch.raful at dimensiondata.com (Mitch Raful (ITaaS)) Date: Wed, 15 Mar 2017 12:04:33 +0000 Subject: [tac_plus] md5 and tac_plus In-Reply-To: References: <14FA6FD3-5A4E-4C27-A85A-2B34DF9B2E74@itaas.dimensiondata.com> Message-ID: I found one of my errors. I was not using the server response?s header for the pseudo_pad to de-obfuscate the packet. However, this is what I get in response 9 10.163.255.153 : Invalid As?&?6? i?P$, Y@\ ????"vp11?g? Any ideas what the tac_plus server is trying to tell me? Mitch Mitch Raful Sr. Network Engineer Dimension Data Cloud Business Unit 43490 Yukon Drive Ashburn, VA 21047 Office: 703-724-8862 Cell: 804-363-0731 From: tac_plus on behalf of Alan McKinnon Date: Wednesday, March 15, 2017 at 5:18 AM To: "tac_plus at shrubbery.net" Subject: Re: [tac_plus] md5 and tac_plus On 15/03/2017 00:22, Mitch Raful (ITaaS) wrote: > I cannot find a Python based tacacs client. I am attempting to write one on my own and can?t figure out the md5 data obfuscation. How does tac_plus handling that. Does it XOR an md5 hash, and add that hash to the session_id + key, version and sequence, and then again if needed? Not quite, but you are on the right track. There are 2 sources I can think of to fins the correct details: - There's an unapproved RFC out there from Cisco that despite never moving out of draft status, is still the way the tacacs protocol works. Usage of the key is in there. - read the tacacsplus code. I recall reading it once and the relevant function was easy to find. don;t have a copy of sources handy to lok for you though. -- Alan McKinnon alan.mckinnon at gmail.com _______________________________________________ tac_plus mailing list tac_plus at shrubbery.net http://www.shrubbery.net/mailman/listinfo/tac_plus itevomcid -------------- next part -------------- An HTML attachment was scrubbed... URL: From mitch.raful at dimensiondata.com Wed Mar 15 14:30:38 2017 From: mitch.raful at dimensiondata.com (Mitch Raful (ITaaS)) Date: Wed, 15 Mar 2017 14:30:38 +0000 Subject: [tac_plus] md5 and tac_plus In-Reply-To: References: <14FA6FD3-5A4E-4C27-A85A-2B34DF9B2E74@itaas.dimensiondata.com> Message-ID: From this code it looks like they only obfuscate the number of bytes of the tacacs body that is the size of an md5 digest, ignoring any bytes at the end whose total length is not equal to an md5 digest. Modulo has to == 0 for (i=0; idatalength); /* null operation if no encryption requested */ if((tac_secret != NULL) && (th->encryption & TAC_PLUS_UNENCRYPTED_FLAG) != TAC_PLUS_UNENCRYPTED_FLAG) { u_char digest[MD5_LBLOCK]; for (i=0; i 0) ? digest : NULL)); buf[i] ^= digest[j]; } } else { TACSYSLOG(LOG_WARNING, "%s: using no TACACS+ encryption", __FUNCTION__); } } /* _tac_crypt */ Mitch Raful Sr. Network Engineer Dimension Data Cloud Business Unit 43490 Yukon Drive Ashburn, VA 21047 Office: 703-724-8862 Cell: 804-363-0731 From: tac_plus on behalf of Alan McKinnon Date: Wednesday, March 15, 2017 at 5:18 AM To: "tac_plus at shrubbery.net" Subject: Re: [tac_plus] md5 and tac_plus On 15/03/2017 00:22, Mitch Raful (ITaaS) wrote: > I cannot find a Python based tacacs client. I am attempting to write one on my own and can?t figure out the md5 data obfuscation. How does tac_plus handling that. Does it XOR an md5 hash, and add that hash to the session_id + key, version and sequence, and then again if needed? Not quite, but you are on the right track. There are 2 sources I can think of to fins the correct details: - There's an unapproved RFC out there from Cisco that despite never moving out of draft status, is still the way the tacacs protocol works. Usage of the key is in there. - read the tacacsplus code. I recall reading it once and the relevant function was easy to find. don;t have a copy of sources handy to lok for you though. -- Alan McKinnon alan.mckinnon at gmail.com _______________________________________________ tac_plus mailing list tac_plus at shrubbery.net http://www.shrubbery.net/mailman/listinfo/tac_plus itevomcid -------------- next part -------------- An HTML attachment was scrubbed... URL: From mitch.raful at dimensiondata.com Thu Mar 16 03:36:26 2017 From: mitch.raful at dimensiondata.com (Mitch Raful (ITaaS)) Date: Thu, 16 Mar 2017 03:36:26 +0000 Subject: [tac_plus] md5 and tac_plus In-Reply-To: References: <14FA6FD3-5A4E-4C27-A85A-2B34DF9B2E74@itaas.dimensiondata.com> Message-ID: Ok, I?ve gotten much closer and can totally de-obfuscate the packet and get this? 8 10.163.252.27 : Invalid AUTHEN/START packet (check keys) Could I also be getting this because the device I am attempting to authenticate with is not permitted in an ACL? Thanks, Mitch Mitch Raful Sr. Network Engineer Dimension Data Cloud Business Unit 43490 Yukon Drive Ashburn, VA 21047 Office: 703-724-8862 Cell: 804-363-0731 From: tac_plus on behalf of Alan McKinnon Date: Wednesday, March 15, 2017 at 5:18 AM To: "tac_plus at shrubbery.net" Subject: Re: [tac_plus] md5 and tac_plus On 15/03/2017 00:22, Mitch Raful (ITaaS) wrote: > I cannot find a Python based tacacs client. I am attempting to write one on my own and can?t figure out the md5 data obfuscation. How does tac_plus handling that. Does it XOR an md5 hash, and add that hash to the session_id + key, version and sequence, and then again if needed? Not quite, but you are on the right track. There are 2 sources I can think of to fins the correct details: - There's an unapproved RFC out there from Cisco that despite never moving out of draft status, is still the way the tacacs protocol works. Usage of the key is in there. - read the tacacsplus code. I recall reading it once and the relevant function was easy to find. don;t have a copy of sources handy to lok for you though. -- Alan McKinnon alan.mckinnon at gmail.com _______________________________________________ tac_plus mailing list tac_plus at shrubbery.net http://www.shrubbery.net/mailman/listinfo/tac_plus itevomcid -------------- next part -------------- An HTML attachment was scrubbed... URL: From alan.mckinnon at gmail.com Thu Mar 16 16:11:56 2017 From: alan.mckinnon at gmail.com (Alan McKinnon) Date: Thu, 16 Mar 2017 18:11:56 +0200 Subject: [tac_plus] md5 and tac_plus In-Reply-To: References: <14FA6FD3-5A4E-4C27-A85A-2B34DF9B2E74@itaas.dimensiondata.com> Message-ID: On 16/03/2017 05:36, Mitch Raful (ITaaS) wrote: > Ok, I?ve gotten much closer and can totally de-obfuscate the packet and > get this? > > > > 8 10.163.252.27 : Invalid AUTHEN/START packet (check keys) > > > > Could I also be getting this because the device I am attempting to > authenticate with is not permitted in an ACL? No, that is a mismatched or wrong tacacs key being used. ACL denies give a more explicit error > > > > Thanks, > > > > Mitch > > > > Mitch Raful > Sr. Network Engineer > Dimension Data Cloud Business Unit > 43490 Yukon Drive > Ashburn, VA 21047 > Office: 703-724-8862 > Cell: 804-363-0731 > > > > > > *From: *tac_plus on behalf of Alan > McKinnon > *Date: *Wednesday, March 15, 2017 at 5:18 AM > *To: *"tac_plus at shrubbery.net" > *Subject: *Re: [tac_plus] md5 and tac_plus > > > > > > On 15/03/2017 00:22, Mitch Raful (ITaaS) wrote: >> I cannot find a Python based tacacs client. I am attempting to write > one on my own and can?t figure out the md5 data obfuscation. How does > tac_plus handling that. Does it XOR an md5 hash, and add that hash to > the session_id + key, version and sequence, and then again if needed? > > > Not quite, but you are on the right track. > > There are 2 sources I can think of to fins the correct details: > > - There's an unapproved RFC out there from Cisco that despite never > moving out of draft status, is still the way the tacacs protocol works. > Usage of the key is in there. > > - read the tacacsplus code. I recall reading it once and the relevant > function was easy to find. don;t have a copy of sources handy to lok for > you though. > > -- > Alan McKinnon > alan.mckinnon at gmail.com > > _______________________________________________ > tac_plus mailing list > tac_plus at shrubbery.net > http://www.shrubbery.net/mailman/listinfo/tac_plus > > > > itevomcid > -- Alan McKinnon alan.mckinnon at gmail.com From mitch.raful at dimensiondata.com Thu Mar 16 18:54:38 2017 From: mitch.raful at dimensiondata.com (Mitch Raful (ITaaS)) Date: Thu, 16 Mar 2017 18:54:38 +0000 Subject: [tac_plus] md5 and tac_plus In-Reply-To: References: <14FA6FD3-5A4E-4C27-A85A-2B34DF9B2E74@itaas.dimensiondata.com> Message-ID: <1D867B69-FCEE-4ECC-B4C1-C49FA320419C@itaas.dimensiondata.com> Ok, then, here?s what I don?t? get. I can decrypt the encrypted message the server sends me back. Doesn?t that mean the keys match? If I change, say the ?client?s? key, the error response stays unreadable. Mitch Mitch Raful Sr. Network Engineer Dimension Data Cloud Business Unit 43490 Yukon Drive Ashburn, VA 21047 Office: 703-724-8862 Cell: 804-363-0731 From: Alan McKinnon Date: Thursday, March 16, 2017 at 12:11 PM To: "Mitch Raful (ITaaS)" , "tac_plus at shrubbery.net" Subject: Re: [tac_plus] md5 and tac_plus On 16/03/2017 05:36, Mitch Raful (ITaaS) wrote: > Ok, I?ve gotten much closer and can totally de-obfuscate the packet and > get this? > > > > 8 10.163.252.27 : Invalid AUTHEN/START packet (check keys) > > > > Could I also be getting this because the device I am attempting to > authenticate with is not permitted in an ACL? No, that is a mismatched or wrong tacacs key being used. ACL denies give a more explicit error > > > > Thanks, > > > > Mitch > > > > Mitch Raful > Sr. Network Engineer > Dimension Data Cloud Business Unit > 43490 Yukon Drive > Ashburn, VA 21047 > Office: 703-724-8862 > Cell: 804-363-0731 > > > > > > *From: *tac_plus on behalf of Alan > McKinnon > *Date: *Wednesday, March 15, 2017 at 5:18 AM > *To: *"tac_plus at shrubbery.net" > *Subject: *Re: [tac_plus] md5 and tac_plus > > > > > > On 15/03/2017 00:22, Mitch Raful (ITaaS) wrote: >> I cannot find a Python based tacacs client. I am attempting to write > one on my own and can?t figure out the md5 data obfuscation. How does > tac_plus handling that. Does it XOR an md5 hash, and add that hash to > the session_id + key, version and sequence, and then again if needed? > > > Not quite, but you are on the right track. > > There are 2 sources I can think of to fins the correct details: > > - There's an unapproved RFC out there from Cisco that despite never > moving out of draft status, is still the way the tacacs protocol works. > Usage of the key is in there. > > - read the tacacsplus code. I recall reading it once and the relevant > function was easy to find. don;t have a copy of sources handy to lok for > you though. > > -- > Alan McKinnon > alan.mckinnon at gmail.com > > _______________________________________________ > tac_plus mailing list > tac_plus at shrubbery.net > http://www.shrubbery.net/mailman/listinfo/tac_plus > > > > itevomcid > -- Alan McKinnon alan.mckinnon at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From philipp_subx at redfish-solutions.com Mon Mar 27 22:32:56 2017 From: philipp_subx at redfish-solutions.com (Philip Prindeville) Date: Mon, 27 Mar 2017 16:32:56 -0600 Subject: [tac_plus] Issue with certain addresses on tacacs+-F4.0.4.27a In-Reply-To: References: Message-ID: <363FDC05-C2A3-419F-8815-253E8174460A@redfish-solutions.com> Can you send output from: (1) lsof -p -n -P (2) netstat -n -t -a Thanks > On Jan 25, 2017, at 12:14 PM, Shinde, Nilesh wrote: > > Hi Daniel, > > If I understand the suggestion correctly, you are pointing to the log with ?tac_connect_single?. > This is an API from the tac plus client library. > We are trying to connect to the server mentioned as tacacs server. > The tacacs server is not listening to all the addresses. > > Thanks, > Nilesh > > > From: Daniel Schmidt [mailto:daniel.schmidt at wyo.gov] > Sent: Wednesday, January 25, 2017 8:55 AM > To: Shinde, Nilesh > Cc: tac_plus at shrubbery.net > Subject: Re: [tac_plus] Issue with certain addresses on tacacs+-F4.0.4.27a > > If I recall correctly, single-connection isn't really supported correctly by vendors - try turning it off on your router. > > On Tue, Jan 24, 2017 at 10:46 PM, Shinde, Nilesh > wrote: > Hi, > > I have noticed that some tacacs+ server with tacacs+-F4.0.4.27a does not listen to all the IPv6 addresses. > Log: > > tac_connect_single: connection failed with 2013:cdba:1002:1304:4001:2005:3257:2000:49: Transport endpoint is not connected > > This shows that the server is not listening to certain addresses. > I used a radius server with this IP and it worked ok. > Is there a patch for this issue? > > Thanks, > Nilesh > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > _______________________________________________ > tac_plus mailing list > tac_plus at shrubbery.net > http://www.shrubbery.net/mailman/listinfo/tac_plus > > > > E-Mail to and from me, in connection with the transaction > of public business, is subject to the Wyoming Public Records > Act and may be disclosed to third parties. > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > _______________________________________________ > tac_plus mailing list > tac_plus at shrubbery.net > http://www.shrubbery.net/mailman/listinfo/tac_plus