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:[email protected]]
Sent: Sunday, May 20, 2018 4:30 AM
To: McDorman, Doug <[email protected]>
Cc: [email protected]
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 <[email protected]>:
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>
[email protected]
www.t-mobile.com
<draft-ietf-oauth-security-topics-05.txt>
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
