Opened 8 years ago

Last modified 8 years ago

#9 new defect

Simplified protocol description "crypto paper"-style

Reported by: nico@… Owned by: draft-ietf-httpauth-mutual@…
Priority: major Milestone:
Component: mutual Version:
Severity: Submitted WG Document Keywords:

Description (last modified by ynir@…)

I find it much, *much* easier to review the cryptographic aspects of any protocol specification by looking at cryptographic protocol paper-style presentations at the highest possible level. In Alice and Bob terms.

E.g., this is a simplified description of EKE in that style:

Client->server: username, cp = E_p(C)
Server->client: sp = E_p(S)
<both compute shared DH secret by decrypting sp (client) or cp (server)>
Client->server: MAC(DH_secret, ...)
<server validates MAC>
Server->client: MAC(DH_secret, ...)

Add a few lines to explain what E_p() and D_p() are, expand on the elided details (e.g., nonces, the "..."), and that's it.

For example, is this a protocol a ZKPP/PAKE? If so, is there any relevant research to reference? I don't see any informative references about cryptographic literature for this protocol. From section 2 at page 10 to page 21 there's nothing about this question, nor is there an exposition of the protocol that helps me figure it out.

It is utterly unclear what kc* are. Public keys I assume, but this isn't stated. Is this protocol basically a DIGEST-like protocol protected by an ephemeral-ephemeral DH key exchange? Is it a ZKPP? This is neither stated nor clear.

Assertions are made about passive and active attack resistance but I don't see any analysis to back them up. And since I can't understand the description of the protocol I can't evaluate the assertions on my own.

As for this:

However, when the client is a Web browser with any scripting
capabilities, the underlying TLS channel used with HTTP/TLS MUST
provide server identity verification. This means (1) the anonymous
Diffie-Hellman key exchange ciphersuite MUST NOT be used, and (2) the
verification of the server certificate provided from the server MUST
be performed.

Huh?! First, I am guessing that the authors mean that the client application should NOT evaluate/run programs obtained from untrusted sources (or the server end of the client's HTTP request). That is, this isn't about scripting capabilities, it's about what the client does with content retrieved with HTTP requests that use this protocol for authentication. Second, this is not reasonable. HTTP stacks cannot be expected to know whether applications evaluate/run response body data as programs. Third, this seems to indicate that this protocol is not a ZKPP/PAKE -- else why have this text at all?

Finally, if this is NOT a ZKPP/PAKE -if it's just another DIGEST-like protocol- then why should anyone bother with it when we have SCRAM [RFC5802]?

[Yoav - 08-Oct-2013 - fixed "component" field]

Change History (2)

comment:1 Changed 8 years ago by nico@…

What exactly are the kc* values?

comment:2 Changed 8 years ago by ynir@…

  • Component changed from basicauth-enc to mutual
  • Description modified (diff)
  • Owner changed from draft-ietf-httpauth-basicauth-enc@… to draft-ietf-httpauth-mutual@…
  • Severity changed from - to Submitted WG Document
Note: See TracTickets for help on using tickets.