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>
_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
