Subject: [http-auth] RFC 7804 One Round-Trip Reauthentication

From: Isen Ng <[email-masked]>
Date: Mon, 28 Nov 2016 14:11:46 +0800

Hi,

I'm looking at RFC 7804, specifically at "One Round-Trip Reauthentication" (
https://tools.ietf.org/html/rfc7804#page-10).

It is said that

"If the client has authenticated to the same realm before (i.e., it
remembers "i" and "s" attributes for the user from earlier
authentication exchanges with the server), it can respond to that
with "client-final-message""

And the example give:

C: GET /resource HTTP/1.1
C: Host: server.example.com
C: Authorization: SCRAM-SHA-256 realm="[email-masked]",
          data=Yz1iaXdzLHI9ck9wck5HZndFYmVSV2diTkVrcU80MDk2JWh2WURwV1VhM
           lJhVENBZnV4RklsailoTmxGLHA9ZEh6YlphcFdJazRqVWhOK1V0ZTl5dGFnOX
           pqZk1IZ3NxbW1pejdBbmRWUT0K

C: [...]

In this case, there no longer is an attribute named "sid" in this
"client-final-message".
How does the server know which user's secret to use to calculate the proof
for matching?

Regards,
Isen

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 30 Nov 2016 12:42:34 +0000

Hi Isen,

On 28/11/2016 06:11, Isen Ng wrote:
> Hi,
>
> I'm looking at RFC 7804, specifically at "One Round-Trip 
> Reauthentication" (https://tools.ietf.org/html/rfc7804#page-10).
>
> It is said that
> C: Host:server.example.com <http://server.example.com>
> C: Authorization: SCRAM-SHA-256 realm="[email-masked] <mailto:[email-masked]>",
> How does the server know which user's secret to use to calculate the 
> proof for matching?
You are right, I messed it up! The client should be sending 
"n=<username>" somewhere in this response.

Are you trying to implement this?

Best Regards,
Alexey

---

From: Isen Ng <[email-masked]>
Date: Thu, 1 Dec 2016 10:22:07 +0800

Hi Alexey,

Yeah, I have implemented the HTTP SCRAM-SHA256 protocol according to this
RFC7804 and is implementing the one round-trip re-authentication at the
moment.

My colleagues and I have agreed upon a workaround and that is to include
the original "sid" in the "client-final-message".
The reason we do so is because the server has to keep a cache of the
original c-nonce and s-nonce for nonce verification anyway. Instead of
trying to maintain a different state for this using a different identifier
and then butchering the "client-final-message" with extra variables, we
decided to simply reuse the session that is already maintained.

This way, the code written to process the "client-final-message" into the
"server-final-message" does need to change at all.
The same code that was used in an regular 2-round-trip authentication can
be used in this 1-trip re-authentication.

Regards,
Isen

*Isen Ng* |  Ninja

*TreeBox Solutions Pte Ltd*
1 Commonwealth Lane #03-01/02
Singapore 149544
*E:* [email-masked]

website <http://treeboxsolutions.com/> |  linkedin
<https://www.linkedin.com/company/treebox-solutions-pte-ltd>  |  twitter
<https://twitter.com/TreeBoxNews>  |  facebook
<https://www.facebook.com/treeboxsolutions>

On Wed, Nov 30, 2016 at 8:42 PM, Alexey Melnikov <[email-masked]>
wrote:

> I'm looking at RFC 7804, specifically at "One Round-Trip Reauthentication"
> (https://tools.ietf.org/html/rfc7804#page-10).
>
> It is said that
>
> You are right, I messed it up! The client should be sending "n=<username>"
> somewhere in this response.
>