Subject: Re: Compound authentication "issue"

From: "Nystrom, Magnus" <[email-masked]>
Date: Thu, 5 Dec 2002 18:45:18 +0100 (W. Europe Standard Time)

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:[email-masked]
> > > > Ireland                             http://www.baltimore.com
> > >
>

---

From: Dale Gustafson <[email-masked]>
Date: Thu, 05 Dec 2002 15:55:11 -0600

Hi Magnus,

A couple of comments inline.

--dg

>You raise some good points, please find my comments below.
[ ... ]

>I note that we do not specify use of the BEEP "serverName"
I'd favor by-reference to TLS, digest-MD5, and BEEP -- amplification & protocol-specific detail should ensure the new document is whole/understandable.

>SACRED-aware application or the patform as such or similar).
>
I can envision a SACRED client that checks it's credential store at 
start-up / periodically.

>Social engineering attacks will always be possible (i.e. simulate a connection to
Not sure what, if anything, we should say in the protocol document, but I see a need for the SACRED client logic to have access to the certificate chain presented to it by the TLS server at connect time.  That would allow the client logic to be more conservative than the normal TLS processing if/when that's necessary.  Didn't see very much about certificates in the current protocol draft.

Also, the protocol document should note what happens for any legitimate corner-cases that
exist because of the combined protocol, such as:

    sTLS authentication succeeds but the server's final digest-MD5
    response fails to authenticate the credential server

That is -- we connected to the right TLS server, the server believes the client knows the
digest-MD5 password(?), but somehow the server failed to prove it also knows the pw.  With digest-MD5, can that happen and, if yes, is that just a mutual-auth error?

>-- Magnus
[ ... ]

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 19 Dec 2002 13:13:57 +0000

I'm trying to figure out what text we need from this thread.
My current guess is that I ought add the following to the 
security considerations:

"Various operations in the SACRED protocol depend upon server authentication 
being provided by server authenticated TLS. SACRED clients SHOULD take care 
that the correct server is at the far end of the TLS "pipe" by performing the 
checks which are listed in section 3.1 of RFC2818 [RFC2818]. Clients SHOULD 
also include the optional BEEP serverName field in their "start" message 
and SHOULD then ensure that the BEEP serverName is consistent with the checks 
on the TLS server described in RFC2818. Failure to carry out these checks 
could allow a spoof server access a user's credential.

If the SACRED account password were to be used in some other, less secure 
protocol using DIGEST-MD5, then it might appear to be the case that a 
man-in-the-middle (MITM) attack could be mounted. However, this is not 
the case since the DIGEST-MD5 client hash includes a client-selected 
"digest-uri-value" which in SACRED's case will be  "sacred/<serverName>". In 
a MITM attack, those values will be something else. A MITM attack as 
described is therefore thwarted because digest-uri-value wouldn't match 
what the SACRED server is expecting."

I've also changed the example in appendix B so it includes the 
severName attribute and therefore (partly) reads:

I: MSG 0 1 . 52 158
I: Content-Type: application/beep+xml
I: 
I: <start number='1' serverName="sacred.example.org">
I:    <profile uri='http://iana.org/beep/TLS'>
I:        <![CDATA[<ready />]]>]]&gt;<![CDATA[
I:    </profile>
I: </start>
I: END

And finally, I added RFC2818 as an informational reference (on the
somewhat dubious basis that its an informational RFC and a standards
track RFC oughtn't reference such a beastie as normative). This is
something the IESG might hit us over the head with later on.

Since I hope to submit the -05 version today, I'd love to get comments
on this, and hopefully before 4pm GMT!

Cheers,
Stephen.

---

From: Dale Gustafson <[email-masked]>
Date: Thu, 19 Dec 2002 11:51:36 -0600

Hi Stephen,

I think your suggested text clarifies the potential risks adequately (as
written).

Beyond that, we should think more about tying the two security protocols (sTLS,
digest-MD5) together, assuming that makes sense from a technical perspective.  I
think Magnus' suggestion to link TLS "domain name" and digest-MD5 "realm name"
together should be looked at more closely. Perhaps others have a better solution.

The larger risk here is that the new combo-protocol offers little or no security
advantage over sTLS with user-id/password authentication which, if true, will
severely limit implementor enthusiasm.

Best Regards,

Dale Gustafson

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 19 Dec 2002 18:09:43 +0000

Hi Dale,

I agree with all that you wrote, except for the "we" bit. I'm not 
at all sure that it'd be in our charter to develop any new mutual
authentication schemes, which is what I believe would be needed to
properly bind sTLS and DIGEST-MD5.

However, there will I believe be a new SASL WG which might want to
take on such things. I'm not sure.

Regards,
Stephen.

---

From: Dale Gustafson <[email-masked]>
Date: Fri, 20 Dec 2002 07:37:43 -0600

Hi Stephen,

> properly bind sTLS and DIGEST-MD5.

You may be right.

Here's another alternative:

SACRED clients will include a unique value received from the TLS server (e.g., during
session negotiation) within their digest-MD5 response.

For example, the TLS server's certID could be used to bind the client's digest-MD5
response to the connected TLS server and no others.  I believe the client's response is
now unusable with any other credential server:

client response = Hash ((Hash(A1)), { nonce-value, ":"nc-value, ":",
                           cnonce-value, ":", qop-value, ":", HEX(H(A2)) }))

where,

   A1 = Hash(user-name:realm:password):server-nonce:client-nonce

   A2 = AUTHENTICATE:digest-uri-value:HEX(TLS-server-certID)

Would that do it?

---

From: Lawrence Greenfield <[email-masked]>
Date: Fri, 20 Dec 2002 12:15:30 -0500

--On Friday, December 20, 2002 7:37 AM -0600 Dale Gustafson 
<[email-masked]> wrote:

> SACRED clients will include a unique value received from the TLS server
> (e.g., during session negotiation) within their digest-MD5 response.

DIGEST-MD5 is a mature standard that's already been deployed in other 
protocols (as a MUST implement for LDAP, for instance).

Changing DIGEST-MD5 is definitely a no-go. If you were going to do that, 
you could just define a new SASL mechanism.

Again, due to the properties of DIGEST-MD5 the attack under consideration 
is thwarted (and I like the proposed text).

Larry

---

From: Dale Gustafson <[email-masked]>
Date: Sat, 28 Dec 2002 11:31:39 -0600

Hi All,

Larry and I exchanged several messages off-list (since it appeared we were
talking about different attacks) and, I think, arrived at a similar conclusion
to that suggested by Stephen earlier:

     "I'm not at all sure that it'd be in our charter to develop any new
     mutual authentication schemes, which is what I believe would be needed
     to properly bind sTLS and DIGEST-MD5."

We agree that my proposed change to bind TLS to digest-MD5 (e.g., by including
the TLS server's certID in the client response) would prohibit an attacker from
transparently relaying the complete digest-MD5 "mutual auth" sequence to some
other (ie., the intended) SACRED credential server.

However, as Larry then points out, the resultant combination-protocol is still
subject to brute force attacks on the digest-MD5 "client response".  This type
of attacker need only capture a single client response and use it to determine
the user's password (via offline dictionary attack).  As a result, any
standardization work necessary to define a new variant of digest-MD5 is probably
unwarranted.

Here is a picture of the attack scenarios under discussion:

 +------------+                +------------+                +------------+
 |  SACRED    |                |   MITM     |                |  SACRED    |
 |  client    |                |            |                |  server    |
 +------------+                +------------+                +------------+
       <----------------------------> <---------------------------->
               TLS session 1                  TLS session 2
       <----------------------------------------------------------->
               digest-MD5 protocol exchange (auth-only)

All of this suggests that some other approach that bolsters the TLS level
"server auth" function would be far more productive for this particular ID.  Use
of digest-MD5 for more than "auth only" might also be an interesting discussion
...

In any event, I don't mean to speak for Larry here -- he'll have to jump in and
add further comments as appropriate.

Regards,

Dale Gustafson

> Lawrence Greenfield wrote:
>