Re: [secdir] review of draft-ietf-oauth-introspection-09

[Stephen Kent <[e-mail]>]

Justin,


> Stephen, thanks for the review. Comments inline.
>
>> ...
>>
>> The text says:
>>
>> The introspection endpoint MUST be protected by a transport-layer 
>> security mechanism as described in Section 4.
>>
>> It might be clearer to say here that the token endpoint MUST 
>> communicate security with the introspection endpoint, and that TLS 
>> 1.2 is the mandatory-to-implement mechanism for such security. Also, 
>> the text should be clearer about the relationship between an 
>> authorization server and an introspection endpoint. In some places 
>> the two terms seem to be used interchangeably.
>>
>
> This language was imported from the soon-to-be-published OAuth Dynamic 
> Registration drafts, including the forward reference. We don’t want to 
> repeat the requirement text.
I didn't review the dynamic registration docs, or I would have made the 
same comment there :-).

If you don't want to repeat requirements text, then I suggest you might 
re-word the sentence
I cited so that it's clearer. Saying that an endpoint must be protected 
by a transport layer security mechanism seems needlessly ambiguous.


> ...
>>
>> How does a protected resource know which other parameters an 
>> introspection endpoint requires/accepts?
>>
>>
>
> We’re assuming it would be either an extension or deployment-specific.
an extension to what?

it seems that a primary motivation for this document is to fix problems 
that arose
because of inadequate specifications for OAuth token syntax. In that 
light, this description
of "other parameters" seems to perpetuate this sort of problem.
>
>
>> This section mandates (MUST) protection against “unauthorized token 
>> scanning” but mandates no standard way to do so. [Also, when would a 
>> scanning “attack” be authorized ;-)]
>>
>>
>
> Is there something more specific we can recommend here? Perhaps in the 
> security considerations section.
yes, the SC section is where there should be suggestions on how to 
protect against such attacks. if you can't recommend something specific, 
then mandating that something be
done seems possibly vacuous, a MUST that will never be realized in 
practice (see RFC 6919).
>
> And the attack could actually take place where an authorized protected 
> resource goes fishing for other valid tokens. The attack isn’t 
> authorized, but the client is … and yes that’s not what we meant but 
> I’m sticking to it.  ;)
so, as I said, the attack is not authorized, and the phrase 
"unauthorized attack" will
make most security experts cringe. is cringing a goal?
>
>> ...
>>
>> IANA must only accept registry updates from the Designated Expert(s)
>>
>> and should direct all requests for registration to the review mailing
>>
>> list.
>>
>> How about:
>>
>> IANA *MUST* accept registry updates *only* from the Designated Expert(s)
>>
>> and *SHOULD* direct all requests for registration to the review mailing
>>
>> list.
>>
>
>
> This text was imported from a template, I’d be glad to change it if 
> there’s a better one.
one should not assume that a doc that has made it through the RFC 
approval process
is perfect.
>
>> Section 3.1.1
>>
>> If a proposed Name matches one already registered as per 7519, ought 
>> it not have an “equivalent” (vs. “comparable”) definition if it is to 
>> be accepted?
>>
>>
>
> It really is comparable, since the contexts are pretty different.
if the contexts are so different, and thus the semantics are not 
equivalent, why is the reuse of the name, and the potential confusion 
acceptable?
>
>> Section 4
>>
>> The text lists four checks to be performed by an authorization 
>> server, yet the introduction to this list says “For instance:” A more 
>> normative introduction would seem appropriate here. I realize that 
>> the text says that not all of these checks may be applicable in all 
>> OAuth 2.0 contexts, but since each check begins with “If the token …” 
>> isn’t that a sufficient caveat?
>>
>>
>
> This is not a normative requirement, since everything is contextual to 
> the nature of the tokens issued by the authorization server.
so you're saying that there is no set of checks that every authorization 
server
can be expected to perform? not even token expiration?


Steve