Section 4.2.2: Keying material

[aboba]

From EKR: https://lists.w3.org/Archives/Public/public-webrtc/2017May/0166.html

Generally, we try to avoid sharing the same initial keying material
with two hashes, which seems to be explicitly what you propose
here. With that said:

• HMAC already has its own shortening algorithm (you hash)

• You should use HKDF to generate fresh subkeys for each
  hash algorithm.

  Note that the OAuth response "key" parameter is a JSON Web Key (JWK)
  or a JWK encrypted with a JWE format. Also note that this is the only
  OAuth parameter whose value is not used directly, but must be
  extracted from the "k" parameter value from the JWK, which contains
  the needed base64-encoded "mac_key".

It's been a while since I looked at this piece of OAuth, but what
key is this encrypted with?

Why are you requiring that the access token be self-encrypted rather
than (say) a table lookup. This is a reasonable procedure, but it's
not the only one, and not really the standard's business.

[aboba]

Related Issue: #1156

[misi]

I hope EKR find the answer in these thoughts:

We do not propose to create more message integrity HMAC in the same time with the same IKM,
just give the possibility for STUN backward compatibility, and simplify according W3C wg decision and
RFC 7635 guidance. So AFAIU only one hash created one time only, but may we need to add some clarification about this.

AFAIU

• To use key shortening is proposed by RFC7635 Appedix B. It propose the key shortening:

The client signals the algorithm supported by it
to the authorization server in the 'alg' parameter defined in
[POP-KEY-DIST]. The authorization server determines the length of
the mac_key based on the HMAC algorithm conveyed by the client. If
the client supports both HMAC-SHA-1 and HMAC-SHA-256-128, then it
signals HMAC-SHA-256-128 to the authorization server, gets a 256-bit
key from the authorization server, and calculates a 160-bit key for
HMAC-SHA-1 using SHA1 and taking the 256-bit key as input.

• pop-key-distribution propose that Client should indicate supported algs to AS in request.

1. https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-02#section-6

The value in the 'alg' parameter together with value from the 'token_type' parameter allow the client to indicate the supported algorithms for a given token type.

2. https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-03#section-4.1
   It propose that the client should send supported algs to the server.

alg: OPTIONAL

Basicly the "alg:" information is used by the AS to find out the appropriate key length.

• WebRTC WG has simplified out gathering and sending the alg capabilities to STUN server.

WebRTC WG decided to simplify it out and only use a fixed key length.
To avoid multiple round-trip times of getting key for every supported algs it ask a IKM key for the longest alg only.

• STUN algs:

1. Actual STUN RFC use only SHA1 for message integrity
2. STUN-bis https://tools.ietf.org/html/draft-ietf-tram-stunbis-12
   STUN Client and Server negotiates alg.
   Actually it propose to use SHA1 and SHA256, but keep it open later for other algs.

• We need more hash alg for stun for backward compatibility, because according STUN-bis STUN client could use SHA1 or SHA256, so we need to create key.

STUN-bis has some built in bid down protection and Hash Agility Plan that will remove SHA1 in a latter point of time, to somehow control bid down attacks.
As it is described in https://tools.ietf.org/html/draft-ietf-tram-stunbis-12#section-15.3

Actually STUN-bis uses both HMAC-SHA-1 and HMAC-SHA-256 for computation of the message integrity.
STUN-bis with "nonce cookie" mechanism and PASSWORD-ALGORITHM/PASSWORD-ALGORITHMS tries to negotiate algs, and this way compute only one hash/message integrity.

• I think we should use HMAC key shortening and fix with an errata the RFC7635 Appendix B:

As it is discussed here: #1156
I think RFC7635 Appendix B meant to work according HMAC key shortening.
Anyhow actually it is conflicting with HMAC key shortening and I think it should be corrected with an errata.

[taylor-b]

I believe this is resolved by #1453. There's already a well-defined algorithm for how to compute an HMAC for a given algorithm given an arbitrarily sized key. @ekr, please re-open if there's more to be done.