Subject: [tram] RFC7635 questions/issues

From: Mészáros Mihály <[email-masked]>
Date: Mon, 3 Oct 2016 23:14:18 +0200

Hi,

I have some questions/issues regarding  RFC7635.

Give me some information and advice why was RFC7635 designed that way,
that all OAuth related parameter should stored inside STUN/TURN client,
instead of storing all these in informations in the application's OAuth
modul?
 
IMHO the application should store OAuth parameters, and take care about
token renewal, and only pass down informations to STUN client that it
really needs.

See my extended version of the figure 2 from RFC7635, so Third Party
Auth in case of WebRTC.

                                                       +---------------+
                                                       |              
=*******+
                                        +------------->+ Authorization
+       *
                                        |              | server       
|       *
                                        |   +----------+(WebRTC
server)|       *  AS+RS,
                                        |   |          |              
|       *  AUTH keys
                               (1)      |   |         
+---------------+       *   (0)
                               Access   |   | 
(2)                             *
                               Token    |   | Access
Token                     *
                               request  |   |   
+                             *
                                        |   | Session
Key                      *
                                        |  
+                                  *
                                        |  
V                                  *
+---------------Web-Browser---------+---+-------+                             
*
|                                   |          
|                              *
|                                   |          
|                              *
|                                   | OAuth    
|                              *
|                          +--------> client   
|                              *
|     Web Application      |        | modul    
|                              *
|                          |        |          
|                              *
|                          |       
+------+----+                              *
|                          |               |   
|                              *
|                 STUN/TURN|               |   
|                              *
|                 Supported|               |   
|                              *
|                 HMAC Algs|            kid|   
|                              *
|                          |        mac_key|   
|                              *
|                          |   access_token|   
|                              *
|                          |               |   
|                              *
|                          |               |   
|                              *
+-------------WebRTC
API------------------------+                              V
|                          |               |    |                      
+-----+=+----+
|                          |               |    |         (3)          
|            |
|                          | +-------------v----+ TURN request + Access
|            |
|    WebRTC Stack          +-+                  | Token                
| TURN       |
|                            |    STUN/TURN    
+----------------------^+ server     |
|                            |                  | Allocate response (4)
|            |
|                           
+-------------------<----------------------+            |
+-----------------------------------------------+                      
+------------+

I think the process should work the following way: (It has some
differences with the actual RFC, RFC7635!)

 1. In my view WebRTC PC must have a read-only field, about the
    supported HMAC alg.
    This information is provided by the STUN/TURN modul of the WebRTC stack.
 2. and only 3 parameters: the kid, the mac_key and the access_token
    must passed to the (ICE agent) STUN/TURN client.
 3. The application should take care about token expiry and renew it.
    And after it pass the new kid, mac_key and access_token credentials
    thorough WebRTC PC interface to the stun client..

 1. RFC7635 says that STUN client should store all OAuth related
    informations, but I don't see and understand the reasons behind it.
    I don't see what are the reasons, and why we should push down all
    OAuth related parameters to STUN client.

    I believe we shouldn't pass all OAuth parameters up and down through
    webRTC interface, because it adds multiple issues, darwbacks
    e.g.
      * The number of such OAuth parameters may vary. To design the
        WebRTC PC API it is much easier if we have fix number of parameters.
      * OAuth parameters over the kid,mac_key,access_token AFAIU are
        almost useless for STUN client.
      * It adds complexity to WebRTC PC interface, and despite these are
        mostly opaque and useless informations for the STUN/TURN client.
        The client need to store these informations.
      * It adds complexity in STUN client and also WebRTC PC, if token
        renewal should be implemented in STUN client level, and also
        it needs a bigger change in STUN/TURN client implementations.

 2. The RFC is mentioning multiple time session key and mac_key terms,
    in Appendix B in example there is this in attribute "key", for me it
    is written in confusing way. AFAIU it speaks from the same thing but
    confusing to use two or three term on it. Maybe only mac_key should
    be used everywhere in the text, to make it little bit less confusing
    for me at least.

All in all could you please shade light on the reasons why the
"STUN/TURN client" should store OAuth parameters and do the access token
renewal. If there is reason, then why it is not good if the OAuth client
modul takes care about renewing the access_token?
As I have mentioned, I think the Web Application OAuth client mudul
should take care about renewal of access_token before token expiry, and
so it needs only to store and deal with All OAuth related parameters. So
my proposal that only a subset of these parameters, parameters that
really used by STUN client should be passed to STUN/TURN client through
the WebRTC PC interface.

I am wondering is there any strong reason to pass and store all OAuth
informations in STUN/TURN client, and trigger renewal from STUN,
rather then leave this for the application OAuth client part?

Please correct me if I am wrong somewhere..
Any comment or correction or advice to my proposed changes will be
highly appreciated.

Thanks,
Misi