Re: Compound authentication "issue"

[Dale Gustafson <degustafson@xxxxxxxxx>]

"Nystrom, Magnus" wrote:

> Hi Dale,
>
> Yes, to protect against MITM you need TLS. But if a SACRED client is
> tricked into setting up a session with a rogue credential server, then
> either the digest-uri-value will be wrong (pointing to the wrong server)
> and hence useless for the attacker (assuming the password is strong
> enough to resist a dictionary attack), or the true server's keypair has
> been compromised.

Maybe I'm missing something here but I don't think any server keys need to be
compromised.  An attacker need only somehow get in front of a real credential server
and negotiate a TLS session with a SACRED client.  Easy enough to do if the attacker
has a valid SSL-cert that is accepted by the SACRED client.

Then it transparently relays to the client a digest-MD5 challenge it has solicited
from the intended/real credential server (e.g. on a different TLS session) and the
compromise is easy from there if (and only if) the client independently choses to
authenticate with the CS that's under attack.  The attacker can be fairly certain the
SACRED client will cooperate.

The attacker doesn't need to know any user password information.  Attacker can capture
all traffic it relays between the SACRED client and server (all of which it sees
in-the-clear).  Attacker can also issue it's own upload/dowload requests to the real
SACRED server since it now has access to the SACRED client's account on the server.

> The server-provided realm value should not help the attacker as long as
> the digest-uri-value is chosen independently by the client.

> The former case above, where a client does connect to a rogue credential
> server, corresponds to V2 in the Requirements RFC (and in the Protocol
> I-D). It means that the client trusts a SACRED server (the TLS auth went
> fine) but that server is not trustworthy. I think it will be difficult to
> protect against this with the client authentication mechanism available.

Sounds ominous.

An attacker should not be able to just purchase a valid SSL-cert and use it to
compromise SACRED clients and their credentials. Right?

> -- Magnus
>
> On Mon, 2 Dec 2002, Dale Gustafson wrote:
>
> > Stephen Farrell wrote:
> >
> > > Great. Since you guys clearly understand this better, can you provide me
> > > with the said text?
> > >
> > > Thanks,
> > > Stephen.
> > >
> > > "Nystrom, Magnus" wrote:
> > > >
> > > > I believe you are right Lawrence. In essence, the client's response is a
> > > > keyed hash of a string of which the digest-uri-value is a part. Since the
> > > > MITM cannot influence that part, the "sacred" serv-type won't be present
> > > > when a MITM is active and the true SACRED server won't therefore accept
> > > > the response (it must not mechanically take the client-provided cleartext
> > > > digest-uri-value and use that when calculating its version of the response
> > > > though, but also check that the serv-type IS "sacred" and the name is its
> > > > own).
> > > >
> > > > Assuming this holds I agree, some text in the Security Considerations
> > > > section seems to be sufficient.
> >
> > It appears the digest-MD5 mutual-auth. method will be dependent on the lower
> > layer sTLS server-auth function to protect against middle-man attacks.
> >
> > For example, if a SACRED client can be tricked into setting up a TLS session
> > with a fake credential server, then this attacker could relay digest-MD5
> > messages to/from a real Credential Server and achieve user-authenticated state
> > by letting the SACRED client do all the digest-MD5 work.  The attacker/MITM must
> > also manage 2 distinct TLS sessions ...
> >
> > If that's true, shouldn't the protocol document specify the relationship between
> > these two inter-dependent protocols (sTLS and digest-MD5)?
> >
> > Will a SACRED client negotiate a TLS session with the web server for
> > "https://www.d1.com/...."; then receive a digest-MD5 challenge from realm =
> > {"sacred/www.d2.com", "sacred/www.d3.com"} ?
> >
> > > >
> > > > Thanks,
> > > > -- Magnus
> > > >
> > > > On Wed, 27 Nov 2002, Lawrence Greenfield wrote:
> > > >
> > > > >
> > > > > Upon further consideration, isn't the man-in-the-middle attack
> > > > > thwarted by the inclusion of "digest-uri-value" in the hash?
> > > > >
> > > > > The DIGEST-MD5 client hash includes a client-selected
> > > > > "digest-uri-value" which in sacred's case will be "sacred/<host>". In
> > > > > a MITM attack, those values will be something else.
> > > > >
> > > > > A MITM attack as described in the WG meeting is thwarted because
> > > > > digest-uri-value wouldn't match what the sacred server is expecting.
> > > > >
> > > > > If it would make people feel better, we can mention this safeguard in
> > > > > the security considerations section.
> > > > >
> > > > > Larry
> > > > >
> > >
> > > --
> > > ____________________________________________________________
> > > Stephen Farrell
> > > Baltimore Technologies,   tel: (direct line) +353 1 881 6716
> > > 39 Parkgate Street,                     fax: +353 1 881 7000
> > > Dublin 8.                mailto:stephen.farrell@xxxxxxxxxxxx
> > > Ireland                             http://www.baltimore.com
> >