Getting the timing right

[Brad Fitzpatrick]

Nothing controversial here.

UTC expire/server-time is fine.  I almost proposed it myself when typing
up my first DH email, but decided that wasn't the point of the email and
went with seconds.  When you said you "had other things in mind" I was
starting to get scared that it'd be some crazy crypto world of time
expiries, but this is fine.  :)

\n as seperator is fine too.  We'll just have to be careful to define it
either as a seperator or as a field ending, to avoid the ambiguity of
whether there's a newline at the end.

- Brad


On Sun, 5 Jun 2005, Paul Crowley wrote:

> An update on how I see the protocol looking with the lifespan stuff in
> place, taking into account Martin Atkin's warnings about NTP.  Note that
> most of this would stay the same in a DSA based protocol; it's not extra
> complexity resulting from the use of HMAC.
>
> Brad, some but not all of your fields start with "openid." - when should
> this be used?
>
> ** Getting a secret, no DH (once per day/week/month per consumer per
> server, depending on expiries)
>
> consumer --> idserver
>
>      openid.mode = generate_hmac_sha1_secret
>
> idserver --> consumer
>
>      hmacsha1_secret = <secret>
>      secret_handle = 1117855428-random_string_19283746
>      secret_expiry = <expiry UTC date>
>      server_time = <UTC date on server>
>
> ** Alternative: Getting a secret with DH
>
> consumer --> idserver
>
>      openid.mode = generate_hmac_sha1_secret_dh
>      openid.dh.p = <modulus>
>      openid.dh.q = <order>
>      openid.dh.g = <generator>
>      openid.dh.gx = <g ^ x mod p>
>
> idserver --> consumer
>
>      openid.dh.gy = <g ^ y mod p>
>      openid.encrypted_hmacsha1_secret = SHA1(gx ^ y mod p) XOR <secret>
>      secret_handle = 1117855428-random_string_19283746
>      secret_expiry = <expiry UTC date>
>      secret_value = 2e47994eec0b1fa16ac62180005fa5651f5e0e14
>      server_time = <UTC date on server>
>
> <secret> must be 160 random bits.
>
> ** Checking identity
>
>    consumer redirect -> UA -> idserver:
>
>        openid.mode = checkid_immediate
>        openid.is_identity = http://bradfitz.com/
>        openid.return_to = http://return.to.com
>        openid.secret_handle = 1117855428-random_string_19283746
>
>    idserver redirect -> UA -> consumer:
>
>        openid.mode = id_res
>        openid.assert_identity = http://bradfitz.com/
>        secret_handle = 1117855428-random_string_19283746
>        valid_from = <UTC date>
>        valid_to = <UTC date>
>        hmac_sha1 = HMACSHA1( secret_value(secret_handle), token_contents )
>
> token_contents are
>
> assert_identity
> <valid_from>
> <valid_to>
> <assert_identity>
> <return_to>
>
> It occurs to me that newline is probably a perfectly safe character to
> use to separate these fields before signing.
>
> OK, now here's the cunning bit.  When you get a secret, you must
> remember not only the handle, the secret and the expiry time - you must
> also note, and offset, the difference between the time I *initiated* the
> request for the secret, and the server_time in the reply.  I can use
> this to compensate for the difference in our clocks.  I'll apply this
> offset when using the valid_to date in the token.
>
> If this offset makes the valid_from date appear to be in the future at
> the time I receive the token, I'll add the difference to the offset, so
> it appears to be in the present.
>
> That way a token can never outlive the valid_to date on the server, and
> never live longer than the difference between the valid from and
> valid_to dates.
>
> In slapdash pseudocode:
>
> # Get secret
>
> now = Date()
> server_secret = get_secret(server)
> server_secret.offset = now - server_time
>
> # Identify
>
> it = get_identity_token(server, server_secret)
> # A token can't live longer than its server secret
> if it.expiry > server_secret.expiry:
>      it.expiry = server_secret.expiry
> # A token can't start life in the future
> now = Date()
> if it.valid_from + server_secret.offset > now:
>      server_secret.offset -= now - it.valid_from
> # When does it expire by our clocks?
> it.true_expiry = it.valid_to + server_secret.offset
>
> --
>    __
> \/ o\ Paul Crowley, paul at ciphergoth.org
> /\__/ http://www.ciphergoth.org/
>
>