On Mon, Apr 22, 2019 at 11:24 AM Andrej Ota <and...@ota.si> wrote: > Hi Joseph, > > Thank you for taking time to review the document. Answers are in-line. > > > On 22 Apr 2019, at 04:49, Joseph Salowey via Datatracker < > nore...@ietf.org> wrote: > > > > Reviewer: Joseph Salowey > > Review result: Serious Issues > > > > As the draft mentions the MD5 based stream cipher used by TACACS+ is > > completely insecure. I think there is too much discussion in the > security > > considerations that may lead one to think that in some cases it provides > > sufficient protection. > > > > Section 10.1 - > > There have been plenty of analysis of the problems with the TACACS+ > message > > protection. This section should just simply say the > encryption/obfuscation > > mechanism provides no integrity protection, no privacy protection and no > replay > > protection. An attacker with access to the data stream should be > assumed to be > > able to read and modify all TACACS+ packets. There are just too many > flaws to > > to enumerate in this document and the rest of the information in this > section > > is wrong or incomplete at best. > > Agreed to replace the section with a simple statement that obfuscation > provides no integrity or replay protection. I'm assuming this refers just > to 10.1 and not the whole of 10. > > [Joe] I think you could probably replace a large portion of 10.2, 3 and 4 as well.
> I think we should still press the point that everyone MUST use obfuscation > as even though the privacy is almost non-existent, it's still slightly > better than plain-text and ROT13. > > [Joe] The current mechanism is roughly equivalent to ROT13 when compared to current encryption mechanisms. I don't think making it a must helps confidentiality, perhaps it helps with authentication below. > > > > Section 10.2 - > > Why not MUST NOT for TAC_PLUS_AUTHEN_STATUS_FOLLOW? Is this really > still used? > > I think Douglas is best positioned to answer this question. > > > > > Section 10.2, 10.3, 10.4 - > > You can probably replace most of these sections with > > "TACACS+ MUST be used with an addition security mechanism to protection > of the > > communication such as IPSEC or a secure network such as described in > 10.5. " > > Agreed. > > > > > Section 10.5.1 and 10.5.2 - > > Why should I care about secrets if they are just providing obfuscation? > Are > > you relying on these secrets for something other than obfuscation? > > Shared secrets also serve to "authenticate" a NAS to a server and vice > versa. > > Which may or may not matter when we state that secure transport MUST be > used. I would like to err on the safe side because mistakes happen and > sometimes unauthorized devices do connect to otherwise secured networks - > intentionally or unintentionally (lab devices and similar come to my mind). > > [Joe] I don't think this section talks about authentication as a goal at all. If this is a goal it should be stated. There will still be some limitations here in that an attacker who can observe the communication will be able to forge and replay messages. I think it could be useful to detect misconfiguration, but there should to be some other mechanism in place to provide stronger authentication. > > > > > Section 10.5.3 - > > Use "less weak" instead of stronger when referring to CHAP, MS-CHAP, and > > MSCHAPv2. Its pretty debatable how much better they are than plaintext > > passwords. > > > > I think "less weak" is acceptable. > > When you wrote that their value is debatable, did that refer to safety of > the authentication session (as in it can be successfully attacked), to > ability of a network attacker (active or passive) to deduce the user's > password, or both? > > My understanding is that they're still viable for the purpose of limiting > the loss of user's password from MiTM attacks. If I'm wrong about this, let > me know so we can be explicit about it in the document as well. > > [Joe] If an attacker can obtain the challenge and response in these mechanisms they can typically carry out an offline dictionary attack to recover the password. They're unsafe to use without a transport that provides confidentiality. > > > Andrej.
_______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
