Re: [OPSAWG] Start of WGLC for TACACS+ document. - Security element (or not)

["Douglas Gash (dcmgash)" <[e-mail]>]

Hi,

Regarding your a) b) c) elements, we are happy to work through the issues
in a different thread, and will wait your final instalment. This specific
question/thread regarded security, hence the handy change of subject.

The reason I would go along the lines of your proposal at the end (but
with a little modification) rather than analysing security of each part,
is because such an inclusive statement covers the situation completely,
and no one will be under any illusions.

Thanks,

Regards,

Doug.

On 06/10/2016 19:51, "Alan DeKok" <[e-mail]> wrote:

>On Oct 6, 2016, at 1:34 PM, Douglas Gash (dcmgash) <[e-mail]>
>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.
>