W3C home > Mailing lists > Public > public-webrtc-logs@w3.org > July 2017

Re: [webrtc-pc] Section 4.2.2: Keying material

From: misi via GitHub <sysbot+gh@w3.org>
Date: Tue, 04 Jul 2017 06:45:41 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issue_comment.created-312794235-1499150739-sysbot+gh@w3.org>
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: https://github.com/w3c/webrtc-pc/issues/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.


-- 
GitHub Notification of comment by misi
Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/1274#issuecomment-312794235 using your GitHub account
Received on Tuesday, 4 July 2017 06:45:48 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:21:40 UTC