Confirm
471
edits
Changes
m
→Client-Side SRP Calculation
=== Client-Side SRP Calculation ===
(TBD) This.. is kind of crazy so far. Needs The picture is incomplete and needs more detail. The server should use Jed's SRP module from https://github.com/jedp/node-srp .
[[File:PICL-IdPAuth-client-SRP.png|client-side SRP]]
The basic idea is that we're using the main-KDF output "srpPW" as a password for the SRP calculation, and leaving the other values ("identity" and "salt") blank, since they're already folded into the password-stretching process.
The SRP "g" (generator) and "N" (prime modulus) should use the 2048-bit value from RFC 5054 Appendix A, which is also used in SRP. Clients should not accept arbitrary g/N values. In the future we might allow alternate parameter sets, in which case the server's first response should indicate which parameter set to use.
The server creates its "B" value according to the SRP protocol and includes it in the response to getSignToken1.
The client does its entire SRP calculation in a single step, after receiving the server's "B" value. It creates its "A" value, computes the shared secret S, and the proof-of-knowledge M1. It sends both "A" and "M1" in the same message (getSignToken2).
The server receives "A", computes the shared secret "S", computes M1, checks that the client's M1 is correct, then derives the shared session key K. It then allocates a signToken and encrypts kA+wrap(kB)+signToken as described below, returning the encrypted/MACed bundle in the response to getSignToken2.
=== getSignToken2 ===
