That looks fine to me fwiw,
Thanks,
S.
On 02/03/2012 01:14 PM, Alexey Melnikov wrote:
On 31/01/2012 10:33, Alexey Melnikov wrote:
On 30/01/2012 05:20, Mike Jones wrote:
[...]
About your third minor issue on RFC 6125 versus RFC 2818, you'll find
that, per the history entries, a previous reference to RFC 2818 was
changed to RFC 6125 in draft 14 at the request of Security Area
Director Stephen Farrell.
I've quickly chatted with Stephen and he said that he only asked the
question and didn't necessarily instructed the WG to do the change from
RFC 2818 to RFC 6125. Keeping this in mind...
If you'd like to see this reference reintroduced, I'd request that
you work with Stephen on specific alternative proposed wording that
is acceptable to both of you.
Ok, I can work with Stephen and Peter Saint-Andre (RFC 6125 co-author)
on some text.
So, here are the proposed changes:
4.2. Threat Mitigation
To protect against token disclosure, confidentiality protection MUST
be applied using TLS [RFC5246] with a ciphersuite that provides
confidentiality and integrity protection. This requires that the
communication interaction between the client and the authorization
server, as well as the interaction between the client and the
resource server, utilize confidentiality and integrity protection.
Since TLS is mandatory to implement and to use with this
specification, it is the preferred approach for preventing token
disclosure via the communication channel. For those cases where the
client is prevented from observing the contents of the token, token
encryption MUST be applied in addition to the usage of TLS
protection. As a further defense against token disclosure, the
client MUST validate the TLS certificate chain when making requests
to protected resources.
I suggest inserting "[RFC5280]" at the end of the last sentence above.
To deal with token capture and replay, the following recommendations
are made: First, the lifetime of the token MUST be limited; one means
of achieving this is by putting a validity time field inside the
protected part of the token. Note that using short-lived (one hour
or less) tokens reduces the impact of them being leaked. Second,
confidentiality protection of the exchanges between the client and
the authorization server and between the client and the resource
server MUST be applied. As a consequence, no eavesdropper along the
communication path is able to observe the token exchange.
Consequently, such an on-path adversary cannot replay the token.
Furthermore, when presenting the token to a resource server, the
client MUST verify the identity of that resource server, as per
Representation and Verification of Domain-Based Application Service
Identity within Internet Public Key Infrastructure Using X.509 (PKIX)
Certificates in the Context of Transport Layer Security (TLS)
[RFC6125].
Please replace the last sentence quoted above with:
Furthermore, when presenting the token to a resource server, the
client MUST verify the identity of that resource server, as per
section 3.1 of [RFC2818].
[Expanded motivation for the change:
I think the reference to RFC 6125 needs to be replaced with the
reference to section 3.1 of RFC 2818. Firstly, the procedure described
in RFC 6125 differs slightly from RFC 2818 (matching of IP addresses is
allowed, wildcards can be used with partial hostnames (e.g. foo* is
allowed, where RFC 6125 doesn't allow for that). Secondly, if RFC 6125
is referenced, then the OAuth document needs to say whether
SRV-ID/URI-IDs are allowed and whether wildcards are allowed.]
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf