Horton

Thread

Commits

  1. Fix use of term "verifier"

  1. use of the term "verifier" with SCRAM

    Peter Eisentraut <peter.eisentraut@2ndquadrant.com> — 2019-08-14T05:59:16Z

    I'm confused by how the code uses the term "verifier" in relation to SCRAM.

ISTM that the code uses the term as meaning whatever is or would be
stored in pg_auth.rolpassword.

I don't see this usage supported in the RFCs.  In RFC 5802,

    verifier        = "v=" base64
                    ;; base-64 encoded ServerSignature.

where

    ServerSignature := HMAC(ServerKey, AuthMessage)
    ServerKey       := HMAC(SaltedPassword, "Server Key")
    AuthMessage     := client-first-message-bare + "," +
                       server-first-message + "," +
                       client-final-message-without-proof

whereas what is stored in rolpassword is

    SCRAM-SHA-256$<iterations>:<salt>$<storedkey>:<serverkey>

where

    StoredKey       := H(ClientKey)
    ClientKey       := HMAC(SaltedPassword, "Client Key")

So while these are all related, I don't think it's accurate to call what
is in rolpassword a SCRAM "verifier".

RFC 5803 is titled "Lightweight Directory Access Protocol (LDAP) Schema
for Storing Salted Challenge Response Authentication Mechanism (SCRAM)
Secrets".  Following that, I think calling the contents of rolpassword a
"secret" or a "stored secret" would be better.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

  2. Re: use of the term "verifier" with SCRAM

    Heikki Linnakangas <hlinnaka@iki.fi> — 2019-08-14T08:41:15Z

    On 14/08/2019 08:59, Peter Eisentraut wrote:
> I'm confused by how the code uses the term "verifier" in relation to SCRAM.
> 
> ISTM that the code uses the term as meaning whatever is or would be
> stored in pg_auth.rolpassword.
> 
> I don't see this usage supported in the RFCs.  In RFC 5802,
> 
>      verifier        = "v=" base64
>                      ;; base-64 encoded ServerSignature.
> 
> where
> 
>      ServerSignature := HMAC(ServerKey, AuthMessage)
>      ServerKey       := HMAC(SaltedPassword, "Server Key")
>      AuthMessage     := client-first-message-bare + "," +
>                         server-first-message + "," +
>                         client-final-message-without-proof
> 
> whereas what is stored in rolpassword is
> 
>      SCRAM-SHA-256$<iterations>:<salt>$<storedkey>:<serverkey>
> 
> where
> 
>      StoredKey       := H(ClientKey)
>      ClientKey       := HMAC(SaltedPassword, "Client Key")
> 
> So while these are all related, I don't think it's accurate to call what
> is in rolpassword a SCRAM "verifier".

Huh, you're right.

> RFC 5803 is titled "Lightweight Directory Access Protocol (LDAP) Schema
> for Storing Salted Challenge Response Authentication Mechanism (SCRAM)
> Secrets".  Following that, I think calling the contents of rolpassword a
> "secret" or a "stored secret" would be better.

RFC 5802 uses the term "Authentication information". See section "2.1 
Terminology":

    o  Authentication information: Information used to verify an identity
       claimed by a SCRAM client.  The authentication information for a
       SCRAM identity consists of salt, iteration count, "StoredKey" and
       "ServerKey" (as defined in the algorithm overview) for each
       supported cryptographic hash function.

But I agree that "secret", as used in RFC5803 is better.

- Heikki

  3. Re: use of the term "verifier" with SCRAM

    Peter Eisentraut <peter.eisentraut@2ndquadrant.com> — 2019-10-10T07:08:37Z

    On 2019-08-14 10:41, Heikki Linnakangas wrote:
>> RFC 5803 is titled "Lightweight Directory Access Protocol (LDAP) Schema
>> for Storing Salted Challenge Response Authentication Mechanism (SCRAM)
>> Secrets".  Following that, I think calling the contents of rolpassword a
>> "secret" or a "stored secret" would be better.

> But I agree that "secret", as used in RFC5803 is better.

Here is my proposed patch to adjust this.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

  4. Re: use of the term "verifier" with SCRAM

    Michael Paquier <michael@paquier.xyz> — 2019-10-10T08:03:16Z

    On Thu, Oct 10, 2019 at 09:08:37AM +0200, Peter Eisentraut wrote:
> Here is my proposed patch to adjust this.

Looks fine to me reading through.  I think that you are right to not
change the descriptions in build_server_final_message(), as that's
described similarly in RFC 5802.  By renaming scram_build_verifier()
to scram_build_secret() you are going to break one of my in-house
extensions.  I am using it to register for a user SCRAM veri^D^D^D^D
secrets with custom iteration and salt length :)
--
Michael

  5. Re: use of the term "verifier" with SCRAM

    Peter Eisentraut <peter.eisentraut@2ndquadrant.com> — 2019-10-12T19:48:37Z

    On 2019-10-10 10:03, Michael Paquier wrote:
> On Thu, Oct 10, 2019 at 09:08:37AM +0200, Peter Eisentraut wrote:
>> Here is my proposed patch to adjust this.
> 
> Looks fine to me reading through.  I think that you are right to not
> change the descriptions in build_server_final_message(), as that's
> described similarly in RFC 5802.

committed

> By renaming scram_build_verifier()
> to scram_build_secret() you are going to break one of my in-house
> extensions.  I am using it to register for a user SCRAM veri^D^D^D^D
> secrets with custom iteration and salt length :)

OK, that should be easy to work around with an #ifdef or two.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services