On Oct 6, 2016, at 1:34 PM, Douglas Gash (dcmgash) <dcmg...@cisco.com> wrote: > Regarding the security concern, the approach we have with the current > document is: > > 1) A statement that the protocol does not provide security in a modern > environment.
I'm happy with that. > 2) The two common approaches to support T+ so that it may be used. OK... > 3) An indication that a version with built-in security is to follow, which > will not require the mitigations in 2) (actually I suspect it may precede > the info document ;-)) Except that the current document doesn't even document CHAP securely. RFC 1994 (published in 1996) says: Each challenge value SHOULD be unique, since repetition of a challenge value in conjunction with the same secret would permit an attacker to reply with a previously intercepted response. Since it is expected that the same secret MAY be used to authenticate with servers in disparate geographic regions, the challenge SHOULD exhibit global and temporal uniqueness. Tho I'll also note that RFC 1994 also doesn't specify a minimum length for the challenge. That is, the document doesn't even meet the security requirements in place in 1994. > We need to make sure there is no ambiguity for 1) for any security review. > No soft-peddalling. T+ provides the function, not the security. I'm fine with that. I want to document historical TACACS+. This means the document needs to answer the following questions: a) can people implement it? b) can people gain the maximum amount of security available in the historical protocol? c) can people be aware of the security concerns and trade-offs with using the historical protocol? The push-back so far shows that the answers are: a) no b) no c) no I suggest these are the wrong answers. *All* of them are the wrong answers. > My question would be: would this dissection of vulnerabilities and > exploration of the attack vectors would help anyone from a security > perspective, when we have established that the approaches 2) are required? Yes. See any of the RADIUS RFCs in the last 5 years. The SAAG reviews require discussion not only of the issues with the new standards, but also of the problems with the historical protocol. > I suspect that we¹d probably miss some, and that may give implementors > more comfort than is afforded by the clear and simple statement. The argument that we can't be perfect isn't a reason to give up entirely. If the statement is anything other than "no one should use this protocol for anything", we might as well *try* to document security issues. > Therefore, for security review, I¹d suggest we keep the statement simple, > as defined above. However, if this statement is not clear enough/correct > in the document, then certainly, it should be clarified. Then the introduction and/or abstract should say: "This document attempts to specify the historical TACACS+ protocol. However, there are many portions of the protocol which are under-specified or unspecified. We cannot second-guess twenty years of practice here. As a result, this specification is incomplete, under-specified, insecure, and should not be used by anyone to implement anything. Please wait for the Standards track document to get the actual TACACS+ specification that people can implement". It shouldn't be a contentious issue. Either document the protocol, or admit we're not going to document the protocol. Alan DeKok. _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
