Re: PAP [was Re: forging a new pppext charter]

At 08:34 AM 2/19/2004 -0800, Bernard Aboba wrote:
> > > How about PAP in EAP-TTLS?
> > > (RFC 1334 is carefully not referenced in
> > > draft-ietf-pppext-eap-ttls-03.txt, but it has a whole subsection 10.2.5
> > > devoted to it.)
>
>Cleartext passwords have been deprecated, and RFC 2284bis makes it clear
>that the omission of cleartext password support in EAP was intentional.
>
>PAP within EAP-TTLS was an unfortunate mistake.  RFC 2284bis explains why
>support of PAP (even within an encrypted tunnel) is dangerous.  This
>exposes a security vulnerability in RADIUS similar to WEP that enables
>cracking of the key stream.  If the RADIUS client does not have a
>cryptographic quality random number generator (e.g. if the client calls
>RAND() to populate the Request Authenticator field in RADIUS), then it
>will be possible for an attacker to do a known plaintext attack on
>RADIUS, and eventually to decrypt "hidden" fields in RADIUS,
>including the User-Password field used to carry PAP passwords.

It was perhaps more careless than careful of me to omit reference to
RFC 1334 in draft-ietf-pppext-eap-ttls-03.txt. But aside from the
name "PAP", the EAP-TTLS draft does not rely on the definition of
PAP in PPP at all. Rather, it relies on "User-Password" in
RFC 2865 (RADIUS), which, amusingly, also fails to mention either
RFC 1334 or 1994. So, although RFC 1994 "disappeared" PAP from PPP,
PAP yet survives in the gulag of deprecated protocols through other
RFCs such as RADIUS.

By making PAP illegal you just create a black market in PAP. If you
need to pass plaintext passwords through EAP, what better way
than to smuggle them through EAP-Generic Token Card? At least with
PAP, the plaintext password is encrypted in RADIUS packets between
hops. However, even when EAP-GTC is enclosed in a tunnel, if the
tunnel endpoint server must proxy forward EAP-GTC it does so in the
clear.

2284bis may claim to have omitted cleartext password support, but
in fact the EAP RFC created equivalent authentication types to each
of the PPP types, PAP and CHAP. CHAP turned into EAP-MD5-Challenge,
and PAP turned into EAP-GTC.

Token card vendors had always used PAP to carry token information,
and EAP needed to support them with a cleartext password method.
One type of token card may utilize a strong signature algorithm,
another might implement a one-time pad; another may be a slip of
paper with "swordfish" written on it. Generic, indeed. It is no
less surprising that simple passwords are being shipped through
EAP-GTC today than that token information has historically been
shipped through PAP. But PAP is more secure, because it is
encrypted when carried in RADIUS.

PAP within EAP-TTLS is neither unfortunate nor a mistake.
EAP-TTLS allows the full range of capabilities represented by the
RADIUS/Diameter attribute set, and to eliminate an attribute like
User-Password would be unnatural and, to my mind, meddlesome. The
user of the protocol should be apprised of the security implications
of the various inner protocols, but his or her choice should not be
constricted artificially. For example, IPsec famously allows the
null cipher. And if PAP is always a better choice than EAP-GTC
(because it is encrypted when proxy forwarded outside the tunnel),
why prohibit PAP and allow EAP-GTC?

Bernard, I don't think 2284bis claims that PAP in a tunnel is dangerous.
It does state that "cleartext passwords cannot be securely used within
EAP, except where encapsulated within a protected tunnel with server
authentication" (section 7.14). It also requires that EAP-GTC not be
used for "cleartext passwords in the absence of a protected tunnel".
Sounds like 2284bis doesn't omit cleartext password support at all;
it only requires that it occur within a tunnel.

You are probably referring to RFC 3759 (RADIUS & EAP), which discusses
vulnerabilities of the RADIUS encryption method when the Authenticator
can repeat. But to say that this exposes a vulnerability similar to WEP
is not accurate. The WEP IV is 24 bits; reuse of that IV is just a
matter of time, and not so much time at that. The RADIUS IV
(Authenticator) is 128 bits and the chance of repetition is nil. If a
RADIUS server generated 16 bits of entropy using rand() and set the
other 112 bits to 0, yes, that would be a problem. But use of a bad
random number generator is not normally considered a flaw in the
protocol, but rather in the implementation. That same RADIUS server
that uses rand() to generate Diffie-Hellman private keys would find all
its TLS sessions cracked anyway. If we avoided any protocol that relied
on implementations not having flawed entropy generators, we'd be left
with very few.

RFC 3759 doesn't claim that RADIUS encryption is dangerous. It does
state, as does RFC 2865, that the implementation should ensure the
uniqueness of the Authenticator in order to avoid these problems.

[By the way, RFC 3759 is incorrect in its discussion of the salt. The
salted key stream cannot be computed from the User-Password key stream
by extending the MD5 calculation with the salt, because of the
termination data that is appended to MD5 messages.]

2284bis does note that RADIUS does not provide for confidentiality
of EAP messages; I think that is the unfortunate mistake. That limits
the use of EAP to protocols that can provide their own data hiding.
Cleartext password is not necessarily the only type of authentication
that has to rely on the transport to hide its contents. Static
biometric identification might have the same requirement, since
biometric values are approximate and cannot be hashed.

I'm not trying to champion PAP as the authentication method of the
future, but see how an argument can be made that PAP in a tunnel is
superior to EAP-MD5-Challege in a tunnel. In both cases, the tunnel
itself is secure against attack, and MitM can be avoided by never using
that password except in a tunnel. But PAP has an advantage in the
security of the backend user database. The server that authenticates
using EAP-MD5-Challenge must have each user's plaintext password
available to it in order to perform the MD5 digest. However, a server
that authenticates using PAP needs only to have an irreversible hash
of the user's password; to authenticate, it simply applies the same
hash operation to the received password and compares. So, with
EAP-MD5-Challenge, the server's database (or any backup thereof)
becomes a juicy target for attackers, and passwords could start falling
like Visa numbers. However, a database thief who comes away with only
password digests intended for use with PAP would have to be content
with the fraction of the passwords that could be recovered via
dictionary attack. Storing a salted and highly-iterated hash of the
password (ala PKCS-5) in the database would keep this fraction small.

So if PAP in a tunnel is unconditionally superior to EAP-GTC, and has
advantages over EAP-MD5-Challenge in certain applications, why not let
it be?

Paul