Re: [OAUTH-WG] Review of draft-ietf-oauth-pop-architecture-00

[Hannes Tschofenig <[e-mail]>]

Hi Reddy,

thanks a lot for your review comments and for failing to notice them.

On 08/28/2014 09:05 AM, Tirumaleswar Reddy (tireddy) wrote:
> My comments:
> 
>  
> 
> 1) Figure 3: Resource server in the response could also generate
> Signature/MAC to prove the client that it is in possession of
> cryptographic keying material.
> 

Correct. Added.

>  
> 
> 2) Section 3.2:
> 
> Will new HTTP headers be defined in one of the PoP drafts for the
> application layer to carry the TLS channel binding information ?

This is up to the solution.
> 
>  
> 
> 3)Section 3.3: It is covering various attack scenarios except active,
> man-in-middle attack.
> 

Section 3 discusses use cases. Section 3.3 describes a scenario where
TLS is not used and the need for an alternative security solution (other
than bearer arises).

I think an active man-in-the-middle use case would not be a good
suggestion ;-)


>  
> 
> 4)Why only discuss TLS and not DTLS ?

The members of the design team where this work came from focused on the
web. I agree that this work is equally applicable to the non-Web
environment (as the recent work in the ACE group had shown).

I would, however, leave it to the ACE working group to explore the use
of OAuth for IoT (with DTLS, CoAP, etc.), if there is enough interest.


> 
>  
> 
> 5)Section 3.4: Enterprise networks, ISP etc. may also deploy HTTP(S) proxy.
> 
Sentence added.

>  
> 
> 6)Please explain scenarios in which using asymmetric cryptography is
> better suited for PoP than using symmetric cryptography.

While symmetric cryptography provides better performance properties the
use of asymmetric cryptography allows the client to keep the private key
locally and never expose it to any other party. I would see this as a
strong security benefit that will more and more important in the future
as we see backend database systems hacked over and over again.


> 
>  
> 
> 7)I don’t see any discussion on HMAC algorithm negotiation b/w the
> client and resource server.
> 
>    It may help to define mandatory to implement and default algorithms.
> 
> 
I added a note about it.


> 
> 8)Protocols like Dynamic Symmetric Key Provisioning Protocol (DSKPP)
> (RFC6063) could be considered for long-term secret b/w the AS and RS.
> 
>  
DSKPP would indeed be a viable solution for distributing symmetric keys.

> 
> 9)Nit> Figure 4: Add arrows for (V) and (IV)
> 
Thanks. Fixed.


>  
> 
> 10)   AS-to-RS Relationship Anonymity:
> 
>  
> 
>       This MAC Token security does not provide AS-to-RS relationship
> 
>       anonymity since the client has to inform the resource server about
> 
>       the resource server it wants to talk to.
> 
> 
> 
> Nit> I think you meant “inform the authorization server about the
> resource server it wants to talk to”
> 

I changed this paragraph.

Thanks again for reading through the document so carefully.

Ciao
Hannes

>  
> 
> Cheers,
> 
> -Tiru
> 
> 
> 
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>