Re: [OAUTH-WG] Pete Resnick's No Objection on draft-ietf-oauth-assertions-17: (with COMMENT)

[Pete Resnick]

On 10/15/14 6:06 PM, Brian Campbell wrote:

Thanks for your review and feedback, Pete. Replies are inline below...


Thanks for addressing the comments, including Barry's followup. Just on 
the questions:


On Tue, Oct 14, 2014 at 2:42 PM, Pete Resnick 
mailto:presn...@qti.qualcomm.com>> wrote:


scope
[...]
   As such, the
  requested scope MUST be equal or lesser than the scope
originally
  granted to the authorized accessor.

s/MUST/will (unless you explain whether it's the server or the client
that's supposed to be obeying that MUST, and for what reason)


They are both supposed to obey it - the client shouldn't ask for more 
and the server will reject the request, if it does.


Is "will" more appropriate than "MUST" here? Or maybe a non 2119 "should"?


Ah, so you're saying that a client could conceivably (either purposely 
or accidentally) try to sneak through a larger scope than it should, and 
the client MUST NOT do that, and the server MUST reject if it gets one. 
OK, that makes sense. (I do tend to like active MUSTs -- the foo MUST do 
X or the bar MUST NOT do Y -- but this is probably OK as is.)



Here and throughout: s/non-normative example/example (As far as I
know,
there are no other kinds in IETF documents.)


I thought I picked that language up from some other draft or RFC but 
I'm now not sure where it came from and can't easily find other 
examples of the same thing.  So I am happy to remove the 
"non-normative" throughout, if it is already understood and/or not 
customary to say so.


Yeah, we've seen other RFCs with such language. I've whined about it in 
the past. Some authors roll their eyes at me. You are welcome to roll 
your eyes if you like, but I find such text silly. :-)


Thanks for the rest of the planned changes. Looks good.

pr

--
Pete Resnick
Qualcomm Technologies, Inc. - +1 (858)651-4478

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Pete Resnick's No Objection on draft-ietf-oauth-assertions-17: (with COMMENT)

[Brian Campbell]

Fair point. I'll add some text saying that in the next revision.

On Wed, Oct 15, 2014 at 5:18 PM, Barry Leiba 
wrote:

>
>>>Assertions used in the protocol exchanges defined by this
>>>specification MUST always be protected against tampering using a
>>>digital signature or a keyed message digest applied by the issuer.
>>>
>>> Why is that? Aren't you using assertions over a protected channel (as
>>> required by the spec) and therefore not need to sign the assertions?
>>> Indeed, why would a self-issued Bearer Assertion need to be signed at
>>> all? Does that even make sense?
>>>
>>>
>> Yes, assertions are sent over a protected channel, which does provide
>> integrity protection for the transport form client to AS and also gives
>> server authentication. But it doesn't provide client authentication, which
>> is kind of the point of the Client Authentication part of this draft. And
>> for authorization the signing or MACing is what authenticates the issuer of
>> the assertion - sometimes the issuer is the client but often the issuer
>> will be a 3rd party system.
>>
>> I do agree with you in one specific case that, if the client is trusted
>> to be the assertion issuer and the client is properly authenticated, then
>> an unsigned assertion could be reasonably used as an authorization grant.
>> But it's a fairly rare and very specific case. And one that can be
>> accommodated in other ways. So it's not worth introducing the complexity
>> and potential security problems that having the signature be option would
>> bring.
>>
>
> In other words, the assertion must be protected against tampering *by the
> party that presents the assertion*.  That is a significant point, and you
> should say it.
>
> Barry
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Pete Resnick's No Objection on draft-ietf-oauth-assertions-17: (with COMMENT)

[Barry Leiba]

>
>
>>Assertions used in the protocol exchanges defined by this
>>specification MUST always be protected against tampering using a
>>digital signature or a keyed message digest applied by the issuer.
>>
>> Why is that? Aren't you using assertions over a protected channel (as
>> required by the spec) and therefore not need to sign the assertions?
>> Indeed, why would a self-issued Bearer Assertion need to be signed at
>> all? Does that even make sense?
>>
>>
> Yes, assertions are sent over a protected channel, which does provide
> integrity protection for the transport form client to AS and also gives
> server authentication. But it doesn't provide client authentication, which
> is kind of the point of the Client Authentication part of this draft. And
> for authorization the signing or MACing is what authenticates the issuer of
> the assertion - sometimes the issuer is the client but often the issuer
> will be a 3rd party system.
>
> I do agree with you in one specific case that, if the client is trusted to
> be the assertion issuer and the client is properly authenticated, then an
> unsigned assertion could be reasonably used as an authorization grant. But
> it's a fairly rare and very specific case. And one that can be accommodated
> in other ways. So it's not worth introducing the complexity and potential
> security problems that having the signature be option would bring.
>

In other words, the assertion must be protected against tampering *by the
party that presents the assertion*.  That is a significant point, and you
should say it.

Barry
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Pete Resnick's No Objection on draft-ietf-oauth-assertions-17: (with COMMENT)

[Brian Campbell]

Thanks for your review and feedback, Pete. Replies are inline below...

On Tue, Oct 14, 2014 at 2:42 PM, Pete Resnick 
wrote:

> Pete Resnick has entered the following ballot position for
> draft-ietf-oauth-assertions-17: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/
>
>
>
> --
> COMMENT:
> --
>
> 3 -
>
>Assertions used in the protocol exchanges defined by this
>specification MUST always be protected against tampering using a
>digital signature or a keyed message digest applied by the issuer.
>
> Why is that? Aren't you using assertions over a protected channel (as
> required by the spec) and therefore not need to sign the assertions?
> Indeed, why would a self-issued Bearer Assertion need to be signed at
> all? Does that even make sense?
>
>
Yes, assertions are sent over a protected channel, which does provide
integrity protection for the transport form client to AS and also gives
server authentication. But it doesn't provide client authentication, which
is kind of the point of the Client Authentication part of this draft. And
for authorization the signing or MACing is what authenticates the issuer of
the assertion - sometimes the issuer is the client but often the issuer
will be a 3rd party system.

I do agree with you in one specific case that, if the client is trusted to
be the assertion issuer and the client is properly authenticated, then an
unsigned assertion could be reasonably used as an authorization grant. But
it's a fairly rare and very specific case. And one that can be accommodated
in other ways. So it's not worth introducing the complexity and potential
security problems that having the signature be option would bring.




> 4.1 -
>
>grant_type
>   REQUIRED.  The format of the assertion as defined by the
>   authorization server.  The value MUST be an absolute URI.
>
> That MUST is unnecessary. It's just definitional from 6749, 4.5 (which,
> as it happens, doesn't use 2119 language for this). s/MUST/will
>

Makes sense.


>
>assertion
>   REQUIRED.  The assertion being used as an authorization grant.
>   Specific serialization of the assertion is defined by profile
>   documents.  The serialization MUST be encoded for transport within
>   HTTP forms.  It is RECOMMENDED that base64url be used.
>
> The MUST seems weird here. Are you saying that the profile could not
> possibly have a serialization for an assertion that did not require
> further encoding? But the RECOMMENDED seems downright wrong: Either an
> implementer *needs* to know the encoding independently of the profile,
> and therefore this needs to be a MUST, or the profile is going to
> describe the encoding, which could be base64url or could be something
> else, and the implementation will do whatever the profile says. If you
> really want to say something here, I suggest replacing the last two
> sentences with:
>
>   If the assertion is going to be transported within HTTP forms, the
>   profile document needs to describe what (if any) encoding will be
>   needed to do so. The base64url encoding is widely implemented and
>   therefore suggested.
>
>
In reading it again, I agree with you that it's weird and not appropriate
here. In fact the JWT profile itself does not require any further encoding.

Barring any objection, I suggest that the last two sentences just be
removed. So it would just be,

  "assertion
  REQUIRED.  The assertion being used as an authorization grant.
  Specific serialization of the assertion is defined by profile
  documents."



> scope
> [...]
>As such, the
>   requested scope MUST be equal or lesser than the scope originally
>   granted to the authorized accessor.
>
> s/MUST/will (unless you explain whether it's the server or the client
> that's supposed to be obeying that MUST, and for what reason)
>

They are both supposed to obey it - the client shouldn't ask for more and
the server will reject the request, if it does.

Is "will" more appropriate than "MUST" here? Or maybe a non 2119 "should"?


>
>   If the scope parameter and/or
>   value are omitted, the scope MUST be treated as equal to the scope
>   originally granted to the authorized accessor.  The Authorization
>   Server MUST limit the scope of the issued access token to be equal
>   or lesser than the scope originally granted to th

[OAUTH-WG] Pete Resnick's No Objection on draft-ietf-oauth-assertions-17: (with COMMENT)

[Pete Resnick]

Pete Resnick has entered the following ballot position for
draft-ietf-oauth-assertions-17: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/



--
COMMENT:
--

3 -

   Assertions used in the protocol exchanges defined by this
   specification MUST always be protected against tampering using a
   digital signature or a keyed message digest applied by the issuer.

Why is that? Aren't you using assertions over a protected channel (as
required by the spec) and therefore not need to sign the assertions?
Indeed, why would a self-issued Bearer Assertion need to be signed at
all? Does that even make sense?

4.1 -

   grant_type
  REQUIRED.  The format of the assertion as defined by the
  authorization server.  The value MUST be an absolute URI.

That MUST is unnecessary. It's just definitional from 6749, 4.5 (which,
as it happens, doesn't use 2119 language for this). s/MUST/will

   assertion
  REQUIRED.  The assertion being used as an authorization grant.
  Specific serialization of the assertion is defined by profile
  documents.  The serialization MUST be encoded for transport within
  HTTP forms.  It is RECOMMENDED that base64url be used.

The MUST seems weird here. Are you saying that the profile could not
possibly have a serialization for an assertion that did not require
further encoding? But the RECOMMENDED seems downright wrong: Either an
implementer *needs* to know the encoding independently of the profile,
and therefore this needs to be a MUST, or the profile is going to
describe the encoding, which could be base64url or could be something
else, and the implementation will do whatever the profile says. If you
really want to say something here, I suggest replacing the last two
sentences with:

  If the assertion is going to be transported within HTTP forms, the
  profile document needs to describe what (if any) encoding will be
  needed to do so. The base64url encoding is widely implemented and
  therefore suggested.

scope
[...]
   As such, the
  requested scope MUST be equal or lesser than the scope originally
  granted to the authorized accessor.
  
s/MUST/will (unless you explain whether it's the server or the client
that's supposed to be obeying that MUST, and for what reason)
  
  If the scope parameter and/or
  value are omitted, the scope MUST be treated as equal to the scope
  originally granted to the authorized accessor.  The Authorization
  Server MUST limit the scope of the issued access token to be equal
  or lesser than the scope originally granted to the authorized
  accessor.

In the first sentence, is this MUST for the server? (That is, shouldn't
it be, "If the scope parameter and/or value are omitted, the server MUST
use the value of the scope originally granted to the authorized
accessor."?) And anyway, don't these two sentences contradict 6749, which
says:

   The authorization server MAY fully or partially ignore the scope
   requested by the client, based on the authorization server policy or
   the resource owner's instructions.
   [...]
   If the client omits the scope parameter when requesting
   authorization, the authorization server MUST either process the
   request using a pre-defined default value or fail the request
   indicating an invalid scope.

Here and throughout: s/non-normative example/example (As far as I know,
there are no other kinds in IETF documents.)

4.1.1 - s/MUST construct/constructs

4.2, client_assertion_type and client_assertion: See comments from 4.1
regarding grant_type and assertion.

4.2.1 - s/MUST construct/constructs

5.2 -

s/MUST identify/identifies

For clarification:
OLD
  Assertions that do
  not identify the Authorization Server as an intended audience MUST
  be rejected.
NEW
  The Authorization Server MUST reject any assertion that does not
  contain the its own identity as the intended audience.
END


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth