[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Compound authentication "issue"
Dale,
You raise some good points, please find my comments below.
On Tue, 3 Dec 2002, Dale Gustafson wrote:
> "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.
But the client connects to a specific SACRED server ("serverName" in the
BEEP start message). The rogue one won't be able to present a certificate
that matches the name of the specified server (c.f. RFC 2818, Section
3.1). But perhaps this should be made more specific in the protocol
document. I note that we do not specify use of the BEEP "serverName"
attribute, although the client should know it. If we specified it, and
also included (by reference or otherwise) the text in RFC 2818 I think we
would be in a more defendable position. (I am also wondering why RFC 3080
does not include text similar to the one in Section 3.1 of RFC 2818, but I
take it now that it is relating to BEEP's framework nature, and the
proper place for such text is in documents implementing a protocol based
on BEEP).
Your message also begs the question as to how/when credential download
actually happens. It could be user-initiated, of course, but a more
natural approach (with perhaps a better user experience), would be to
"trigger" this based on some event, e.g.: The user is asked to sign a
form with JavaScript signText(). This creates a call to PKCS#11, and if a
"SACRED-aware" PKCS #11 module is present and active, it will then contact
a pre-configured SACRED server to get the credential. Another alternative
is to have credential download to happen automatically at login (to the
SACRED-aware application or the patform as such or similar). Social
engineering attacks will always be possible (i.e. simulate a connection to
a SACRED server through a plug-in, perhasp), so users must always take
care not to do a sacred authentication to unknown hosts.
To conclude then, at this point I am inclined to suggest that we add
wording similar to what is in Section 3.1 of RFC 2818, i.e. that the
SACRED client MUST check that the server name as presented through TLS is
acceptable and the intended (BEEP "serverName" SHOULD (MUST?) be used, and
must map directly or otherwise to the name authenticated in the TLS
handshake.
-- Magnus
> 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
> > >
>