Re: [secdir] Secdir last call review of draft-ietf-opsawg-tacacs-13

[Joseph Salowey <[e-mail]>]

On Mon, Apr 22, 2019 at 11:24 AM Andrej Ota <[e-mail]> 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 <
> [e-mail]> 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.