[OPSAWG] draft-ietf-opsawg-tacacs-??: 9.1. General Security of The Protocol

[Andrej Ota <[e-mail]>]

Hi Everyone,

This covers section 9.1. exclusively. I'm compiling list of changes for other sections changed since the -06 revision while you have a chance to review this section.


New text in -07:
> 9.1.  Overall Security of The Protocol
> 
> TACACS+ protocol does not include a security mechanism that would
> meet modern day requirements.  Support for MD5-based crypto pad
> encryption fails to provide any kind of transport integrity, which
> presents at least the following risks:

Change:
1) Verbiage in -06 only vaguely referred to an "absence of a security mechanism that would meet modern day requirements".
We explicitly called out "MD5-based crypto pad" as deficient crypto algorithm and specified "transport integrity" as the area of deficiency. Operators should not need to read the rest of the document to deduce the name of the crypto algorithm that we claim is broken beyond repair.

2) We removed the sentence "The choice of obfuscating the body but not the packet header means that an attacker can modify the header without detection." as we felt it can be read as to imply that the packet body cannot be modified without detection. In fact it can be and effects can be disastrous to security.

Reason for the change:
1) We believe that as this is a technical document, we should not shy away from at least some technicalities to substantiate claims that we're making. E.g. we found "meeting modern day requirements" could benefit from some explanation in what ways it fails. We also think there's no problem stating what is the encryption protocol that the section refers to.

2) We removed an ambiguous sentence that may lead to wrong security assumptions. I.e. that the changes in the body of the packet will be detected.


>   Accounting information may be modified by the man-in-the-middle
>   attacker, making such logs unsuitable and untrustable for auditing
>   purposes.
> 
>   Only the body of the request is encrypted which leaves all header
>   fields open to trivial modification by the man-in-the-middle
>   attacker.
> 
>   Invalid or misleading values may be inserted by the man-in-the-
>   middle attacker in various fields at known offsets to try and
>   circumvent the authentication or authorization checks even inside
>   the encrypted body.

Change:
1) This adds more technical explanation to both substantiate the claim that the protocol provides no transport integrity and the ways in which this may result in a security threat. There was no corresponding verbiage in -06 or previous versions.

Reason for the change:
1) We do not shy away from technical information in a technical document as understanding some of the ways that the threat can be realized serves to better inform operators when estimating the risk in their own environment.


> While the protocol provides some measure of transport privacy, it is
> vulnerable to at least the following attacks:

Change:
1) In line with previous paragraph, this paragraph announces that we'll be enumerating problems with the lack of transport privacy where privacy is the other side of the integrity coin when it comes to transport security.


>   Brute force attacks exploiting increased efficiency of MD5 digest
>   computation.
> 
>   Known plaintext attacks which may decrease the cost of brute force
>   attack.
> 
>   Chosen plaintext attacks which may decrease the cost of a brute
>   force attack. 
>  
>   No forward secrecy means that original data may be revealed at the	
>   later time and still provide valuable information to the attacker.	

Change:
1) Again, without shying away from technical details, we explain what are known attacks against the protocol that will likely succeed due to the lack of an adequate transport privacy.


> Even though, to the best knowledge of authors, this method of	
> encryption wasn't rigorously tested, authors feel that enough	
> information is available that it is best referred to as "obfuscation"	
> and not "encryption" and as such it MUST NOT BE relied upon to	
> provide privacy.

Change:
1) All together this paragraph recaps what it means that there's no transport privacy. We explicitly stated that authors don't know about any public research about the security of the protocol and its application, though enough information is available that we thought that a "MUST NOT" can be used. We updated this later in -08 to remove the "MUST NOT" as we already captured that part in the other parts of the text.


> For example, a "session_id" can be replaced by an alternate one,
> which could allow an unprivileged administrator to "steal" the
> authorization from a session for a privileged administrator.  An
> attacker could also update the "flags" field to indicate that one or
> the other end of a connection requires TAC_PLUS_UNENCRYPTED_FLAG,
> which would subvert the obfuscation mechanism.

The text was not changed from the -06 but we ultimately removed it whole in -10. At the time we were still reviewing this paragraph as we felt it contained factual errors, omissions and simply didn't feel like it fits in this spot. Below is the reasoning as to why we thought that. Ultimately all of these combined were reasons to remove this paragraph in revision -10.

1) It was not and still remains unclear to the authors how replacing a "session_id" would directly lead to stealing the security of the entire transmission path that would be different or easier to execute compared to an attack on the encryption itself. To successfully insert oneself in the path between device and server to change "session_id" would necessitate knowing the key to correctly decrypt and encrypt traffic as the key is a mandatory part of first MD5 has computation[1]. What is the value of pointing out a harder-to perform attack if there are easier attacks available that lead to what this description implies?

2) While "stealing the authorization from a session for a privileged administrator" is a bad result, it's not actually done in this way, which requires knowing or brute-forcing the secret key. Easier and much more reliable way is to exploit lack of transport integrity and change the obfuscated packet body. We're still trying to understand if this information is worth keeping as it implies "could allow" as opposed to an easier attack which authors feel confident can simply be stated as "allows".

3) As per 1997/8 draft[2] and tac_plus implementations in the wild, modifying TAC_PLUS_UNENCRYPTED_FLAG can't lead to decryption of the session so this looks like a factual error. We have not managed to test a huge variety of servers to confidently claim this never happens, but it certainly can't happen with current implementations which respect the following statement from the 1997/8 draft[2]: "NOTE: implementations should take care not to skip decryption simply because an incoming packet indicates that it is not encrypted." A common server implementation of this note is available in tac_plus code[3] which unconditionally decrypts the packet if the shared secret key is set and, almost as a joke on 1997/8 draft authors, sets TAC_PLUS_UNENCRYPTED_FLAG on all replies.

4) As far as the current draft goes, the "TAC_PLUS_UNENCRYPTED_FLAG attack" looked impossible[1] so this was ultimately suspect and marked to be thrown out completely in one of the next revisions. I have to mention for completeness that the current version of the draft changes the prescription in a mostly compatible way. 1997/8 draft specified that all packets must be decrypted and the sanity checked while ignoring the encryption flag which already made the described attack a dud. The current revision of the draft is specifying that if the key is configured, any attempt at passing an unencrypted flag should be denied without resorting to deobfuscation and sanity checking. In most of the cases the end result will be the same, but we can identify some corner cases (mostly in accounting, but theoretically possible in authentication and authorization as well) where the 1997-compliant server wouldn't pass the muster for the current draft. As far as the attack goes, it doesn't work like the -06 text implies it might.

As usual, this is security. Mistakes are easy to make and consequences are usually catastrophic. Do raise alarm if there's something missing from the reasoning.


> For this reasons, users deploying TACACS+ protocol in their
> environments MUST limit access to known clients and MUST control the
> security of the entire transmission path.  Attacks who can guess the
> key or otherwise break the obfuscation WILL gain unrestricted and
> undetected access to all TACACS+ traffic.  The security risk of such
> attack succeeding against a centralised AAA system like TACACS+
> cannot be overstated.

Changes:
1) Main change is to resort to MUST statements missing from the original verbiage: "... MUST limit access ...", "... MUST control the security of the entire transmission path". Considering everything else stated in this section, it is opinion of the authors that MUST is a proportionate verb to use to impress on operators how insecure is the protocol and how critical it is to control the environment where it's deployed.

Reason for the change:
1) We felt at the time that the original verbiage in -06 didn't go far enough to impress on operators what is the minimal requirement to safely deploy the protocol.


Changes in -08 revision:
1) Changes to this section in -08 revision were minimal. Explanation of what is "forward secrecy" was removed as that is a well known and unambiguous term.
2) Removed a "MUST NOT BE relied ... to provide privacy" sentence as we felt that other parts of the section already capture this.

Changes in -09 revision:
1) Fixing typos.

Changes in -10 revision:
1) Added the "authors feel" verbiage to better separate fact from opinion.
2) Removed the paragraph calling out "session_id" and "TAC_PLUS_UNENCRYPTED_FLAG attack" as it contained factual errors and the rest of the document already captured the examples of threats related to the lack of transport privacy and/or integrity.


The totality of these changes lead to what is the current content of section "9.1 General Security of The Protocol".


[1] See section 3.7. Data Obfuscation.
[2] https://tools.ietf.org/html/draft-grant-tacacs-02 <https://tools.ietf.org/html/draft-grant-tacacs-02>
[3] https://github.com/supertylerc/tac_plus/blob/a51f9d377d7fdbc87ad92c87e914c669a2f09ccd/src/packet.c#L148 <https://github.com/supertylerc/tac_plus/blob/a51f9d377d7fdbc87ad92c87e914c669a2f09ccd/src/packet.c#L148>