Re: [OAUTH-WG] draft-ietf-oauth-security-topics

[Torsten Lodderstedt <[e-mail]>]

Hi Doug,

Am 22.05.18 um 07:48 schrieb McDorman, Doug:
> I attached 2 diffs which should help highlight the changes.
thanks, that helped a lot!
>
> To summarize:
> Added 	1.1.  Notational Conventions
>
> Section 3.1.1.  Attacks on Authorization Code Grant
> FROM
> control, say "https://www.evil.com".
> TO
> control, say "https://www.evil.example.com".
>
> Section 3.1.2.  Attacks on Implicit Grant
> FROM
> attacker's control, say "https://www.evil.com".
> TO
> attacker's control, say "https://www.evil.test.com".
>
> FROM
> "redirect_to=https://client.evil.com" into the redirect URI and
> TO
> "redirect_to=https://client.evil.test.com" into the redirect
>
> FROM
> %253Dhttps%253A%252F%252Fclient.evil.com%252Fcb HTTP/1.1
> TO
> %253Dhttps%253A%252F%252Fclient.evil.test.com%252Fcb HTTP/1.1
>
> FROM
> redirect_to%3Dhttps%3A%2F%2Fclient.evil.com%2Fcb
> TO
> redirect_to%3Dhttps%3A%2F%2Fclient.evil.test.com%2Fcb#
>
> FROM
> the URL "https://evil.example.com/cb".
> TO
> the URL "https://client.evil.test.com/cb".
>
> FROM
> Location: https://client.evil.com/cb
> TO
> Location: https://client.evil.test.com/cb
>
> FROM
> https://client.evil.com/cb#access_token=2YotnFZFEjr1zCsicMWpAA&...
> TO
> https://client.evil.test.com/cb#	
> 	access_token=2YotnFZFEjr1zCsicMWpAA&...
>
> FROM
> (4) The attacker's page at client.evil.com can access the fragment
> 	and obtain the access token.
> TO
> (4)  The attacker's page at client.evil.test.com can access the	
> 	fragment and obtain the access token.

I took the liberty to use the "example" TLD in all examples as 
recommended in RFC 2606.

>
> Section 	3.3.2.  Access token in browser history
> FROM
> Actually [RFC6750]discourages this practice and asks to transfer	 	
> TO
> Actually [RFC6750] discourages this practice and asks to transfer
done
> Section 3.7.1.1.  Metadata (line break added to avoid line too long)
> FROM
> "access_token_resource_server":"https://hostedresource.example.com/path1",
> TO
> "access_token_resource_server":	
> 	"https://hostedresource.example.com/path1",
done
>
> Section 3.8.2.  Clients as Open Redirector (uppercase the NOT)		   	 	
> FROM
> Client MUST not expose URLs which could be utilized as open
> TO
> Client MUST NOT expose URLs which could be utilized as open
done
>
> Added section 3.10.  Cryptographic Agility
> NEW
>    Cryptographic agility is the ability to change algorithms if the need	
> 		 	  arises. For example RS256 does not have the same formal validation	
> 		 	  that PS256 does, so vulnerabilities might be found in RS256.	
> 		 	  Similarly quantum computing may make elliptic curve ES256 or EdDSA	
> 		 	  [RFC8037] a better option than RS256. So the protocol must be able to	
> 		 	  adapt to other cryptographic algorithms. Over time cryptographic	
> 		 	  algorithms are expected to become obsolete (DES, RC4, MD5, SHA1) often	
> 		 	  with long time frames but new research and vulnerabilities can sometimes	
> 		 	  shorten the time dramatically.	
> 		 		
> 		 	  The implementations SHOULD implement and test additional cryptographic	
> 		 	  algorithms to support cryptographic agility. Typically implementations	
> 		 	  indicate that they MUST implement RS256 (RSASSA-PKCS-v1_5 using SHA-256	
> 		 	  hash algorithm) but PS256 (RSASSA-PSS using SHA-256 hash algorithm and	
> 		 	  MGF1 mask generation) has a better mathematical foundation of security	
> 		 	  and [RFC8017] recommends a gradual transition to EMSA-PSS in PS256 is	
> 		 	  recommended as a precaution against future developments.
I agree crypto agility is a very important topic. I'm not quite sure 
whether this topic should be discussed in this document for two reasons:
- this draft is about OAuth-specific security threats, I don't see a 
direct relationship
- the draft nowhere talk about any crypto algorithms

What does the WG think?
>
> Section 7.1.  Normative References
> NEW
> 	[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate	
> 	Requirement Levels", BCP 14, RFC 2119,	
> 	DOI 10.17487/RFC2119, March 1997,	
> 	<http://www.rfc-editor.org/info/rfc2119>.

done
>
> 	 [RFC8017]  Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch,	
> 	"PKCS #1: RSA Cryptography Specifications Version 2.2",	
> 	  RFC 8017, DOI 10.17487/RFC8017, November 2016,	
> 	 <https://www.rfc-editor.org/info/rfc8017>.	
> 		 		
> 	 [RFC8037]  Liusvaara, I., "CFRG Elliptic Curve Diffie-Hellman (ECDH)	
> 	and Signatures in JSON Object Signing and Encryption (JOSE)",	
> 	RFC 8037, DOI 10.17487/RFC8037, January 2017,	
> 	 <https://www.rfc-editor.org/info/rfc8037>.
related to your text proposal - not adopted for the moment
>
> Section 7.2. Informative References
> FROM
> draft-ietf-oauth-jwsreq-15 (work in progress), July 2017.	 		
> TO
> draft-ietf-oauth-jwsreq-16 (work in progress), April 2018.
thanks for pointing this out. My local environment somehow fetched 
outdated data. It's been corrected now.
>
> FROM
> mtls-07 (work in progress), January 2018.
> TO
> mtls-08 (work in progress), May 2018.
>
> FROM
> tokbind-https-12 (work in progress), January 2018.
> TO
> tokbind-https-14 (work in progress), May 2018.
>
> Does that help?
yes!

best regards,
Torsten.
>
> Thanks,
>
> Doug
>
> -----Original Message-----
> From: Torsten Lodderstedt [mailto:[e-mail]]
> Sent: Sunday, May 20, 2018 4:30 AM
> To: McDorman, Doug <[e-mail]>
> Cc: [e-mail]
> Subject: Re: draft-ietf-oauth-security-topics
>
> Hi Doug,
>
> thanks for your feedback. I changed the names to comply to RFC 2606.
>
> Can you please add all proposals to the body of your posting (including section/page references)? Otherwise, it’s nearly impossible to discuss proposals on the list.
>
> best regards,
> Torsten.
>
>> Am 08.05.2018 um 08:48 schrieb McDorman, Doug <[e-mail]>:
>>
>> Hi working group, I made some edits to the current draft of this document. Edited version attached.
>>   
>> The changes probably are not in the exact desired format, I have not edited an RFC before and I am not familiar with the tools and process.
>>   
>> Summary:
>> 	• I added a section 3.10.  Cryptographic Agility
>> 	• The domain evil.com is used but that is a real URL so I changed references to be evil.test.com, According to  https://tools.ietf.org/html/rfc2606  test.com should be safe to use in documentation.
>> 	• There was one wrong URL of https://evil.example.com/cb, which should have been https://client.evil.com/cbalthough I changed to https://client.evil.test.com/cb to be consistent with the other changes from evil.com to test.com
>> 	• Updated some of the references to newer versions
>> 	• A few other minor spacing issues
>>   
>> Let me know if I can clarify anything or provide additional assistance.
>>   
>> Thanks,
>>   
>> Doug
>>   
>> Doug McDorman
>> Principal Architect, Security
>>   
>> <image002.jpg>
>> [e-mail]
>> www.t-mobile.com
>>   
>> <draft-ietf-oauth-security-topics-05.txt>