Re: [OAUTH-WG] New Version Notification for draft-meyerzuselhausen-oauth-iss-auth-resp-01.txt

[Joseph Heenan]

I agree, it is in redundant in the JARM case.

I find the text in 
https://www.ietf.org/archive/id/draft-meyerzuselhausen-oauth-iss-auth-resp-01.html#name-security-considerations
 (the 4th paragraph where JARM & JWTs) are mentioned a bit confusing - I think 
it would be good to say something along the lines of:

Although integrity protection is not necessary to prevent mixup, any 
authorization response method that includes a JWT with an ‘iss' (for example, 
JARM or OIDC hybrid flow) will prevent the attack (assuming the client is 
validating the iss).


I’m not entirely sure I understand what "MUST NOT allow multiple authorization 
servers to return the same issuer identifier during registration” means as I 
don’t think https://tools.ietf.org/html/rfc7591 returns the issuer?

It might be clearer to say something like “When 
https://tools.ietf.org/html/rfc8414 is used the client MUST implement the 
validation described in https://tools.ietf.org/html/rfc8414#section-3.3. When 
authorization server details can be manually configured in the client, the 
client must verify that all issuer values are unique.” (Or at least something 
along those lines, I’m sure my wording can be improved. But if the client is 
correctly implementing rfc8414 or OIDC discovery [and does not have any 
manually configured authorization servers] then there’s no requirement for any 
further checks that the issuer is unique.)

Joseph


> On 3 Nov 2020, at 07:01, Vladimir Dzhuvinov  wrote:
> 
> This can potentially occur. If JARM is used "iss" becomes redundant. To me 
> JARM is an "enhanced" iss.
> 
> If both are included a sensible client should make sure the iss and the JARM 
> iss match.
> 
> My suggestion is to not require iss when a JARM is present, but in case both 
> do occur to have the client check both.
> 
> Vladimir
> 
> On 02/11/2020 22:34, Takahiko Kawasaki wrote:
>> Hi Karsten,
>> 
>> The specification mentions JARM. Does this specification require the iss 
>> response parameter even when JARM is used? That is, should an authorization 
>> response look like below?
>> 
>> HTTP/1.1 302 Found
>> Location: https://client.example.com/cb?response={JWT}={ISSUER} 
>> 
>> 
>> Or, can the iss response parameter be omitted when JARM is used?
>> 
>> A small feedback for the 3rd paragraph in Section 4: s/identifes/identifies/
>> 
>> Best Regards,
>> Taka
>>  
>> 
>> On Tue, Nov 3, 2020 at 3:13 AM Vladimir Dzhuvinov > > wrote:
>> Thanks Karsten, looks good to me now, no further comments.
>> 
>> Vladimir
>> 
>> On 02/11/2020 09:54, Karsten Meyer zu Selhausen wrote:
>>> Hi all,
>>> 
>>> Daniel and I published a new version of the "iss" response parameter draft 
>>> to address the feedback from the WG.
>>> 
>>> Changes in -01:
>>> 
>>> Incorporated first WG feedback
>>> Clarifications for use with OIDC
>>> Added note that clients supporting just one AS are not vulnerable
>>> Renamed metadata parameter
>>> Various editorial changes
>>> 
>>> We would like to ask you for further feedback and comments on the new draft 
>>> version.
>>> 
>>> Best regards,
>>> Karsten
>>> 
>>>  Forwarded Message 
>>> Subject:New Version Notification for 
>>> draft-meyerzuselhausen-oauth-iss-auth-resp-01.txt
>>> Date:   Sun, 01 Nov 2020 23:31:42 -0800
>>> From:   internet-dra...@ietf.org 
>>> To: Karsten Meyer zu Selhausen  
>>> , Karsten zu Selhausen 
>>>  
>>> , Daniel Fett 
>>>  
>>> 
>>> 
>>> A new version of I-D, draft-meyerzuselhausen-oauth-iss-auth-resp-01.txt
>>> has been successfully submitted by Karsten Meyer zu Selhausen and posted to 
>>> the
>>> IETF repository.
>>> 
>>> Name: draft-meyerzuselhausen-oauth-iss-auth-resp
>>> Revision: 01
>>> Title: OAuth 2.0 Authorization Server Issuer Identifier in Authorization 
>>> Response
>>> Document date: 2020-11-01
>>> Group: Individual Submission
>>> Pages: 10
>>> URL: 
>>> https://www.ietf.org/archive/id/draft-meyerzuselhausen-oauth-iss-auth-resp-01.txt
>>>  
>>> 
>>> Status: 
>>> https://datatracker.ietf.org/doc/draft-meyerzuselhausen-oauth-iss-auth-resp/
>>>  
>>> 
>>> Html: 
>>> https://www.ietf.org/archive/id/draft-meyerzuselhausen-oauth-iss-auth-resp-01.html
>>>  
>>> 
>>> Htmlized: 
>>> https://tools.ietf.org/html/draft-meyerzuselhausen-oauth-iss-auth-resp-01 
>>> 
>>> Diff: 
>>> https://www.ietf.org/rfcdiff?url2=draft-meyerzuselhausen-oauth-iss-auth-resp-01
>>>  
>>> 

Re: [OAUTH-WG] Android App Links (AKA Universal Links)

[Dick Hardt]

Thanks Joseph.

George Fletcher ran a great session on the topic at the last IIW as well.

George: do you have a link?

ᐧ

On Tue, Nov 3, 2020 at 11:09 AM Joseph Heenan  wrote:

> Hi Dick
>
> I didn’t attend the call so don’t know the background of this and the
> exact situation, but the general problem is mostly where the Authorization
> Server’s app is *not* installed. In that case Android falls back to much
> weaker mechanisms that allow other apps to get a look in. App links also
> aren’t consistently supported across all commonly used android browsers
> which causes further problems.
>
> In general to do app2app oauth redirections securely on Android it’s
> necessary for both apps to fetch the /.well-known/assetlinks.json for the
> url they want to redirect to, and verify that the intent the app intends to
> launch to handle the url is signed using the expected certificate. Web2app
> flows are trickier, on both iOS and on Android. There were lengthy
> discussions on at least the Android case at OAuth Security Workshop this
> year (recordings available).
>
> Joseph
>
>
> On 20 Oct 2020, at 00:09, Dick Hardt  wrote:
>
> Hey Vittorio
>
> (cc'ing OAuth list as this was brought up in the office hours today)
>
> https://developer.android.com/training/app-links
>
> An app is the default handler and the developer has verified ownership of
> the HTTPS URL. While a user can override the app being the default handler
> in the system settings -- I don't see how a malicious app can be the
> default setting.
>
> What am I missing?
>
> /Dick
> ᐧ
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Android App Links (AKA Universal Links)

[Joseph Heenan]

Hi Dick

I didn’t attend the call so don’t know the background of this and the exact 
situation, but the general problem is mostly where the Authorization Server’s 
app is *not* installed. In that case Android falls back to much weaker 
mechanisms that allow other apps to get a look in. App links also aren’t 
consistently supported across all commonly used android browsers which causes 
further problems.

In general to do app2app oauth redirections securely on Android it’s necessary 
for both apps to fetch the /.well-known/assetlinks.json for the url they want 
to redirect to, and verify that the intent the app intends to launch to handle 
the url is signed using the expected certificate. Web2app flows are trickier, 
on both iOS and on Android. There were lengthy discussions on at least the 
Android case at OAuth Security Workshop this year (recordings available).

Joseph


> On 20 Oct 2020, at 00:09, Dick Hardt  wrote:
> 
> Hey Vittorio
> 
> (cc'ing OAuth list as this was brought up in the office hours today)
> 
> https://developer.android.com/training/app-links 
> 
> 
> An app is the default handler and the developer has verified ownership of the 
> HTTPS URL. While a user can override the app being the default handler in the 
> system settings -- I don't see how a malicious app can be the default setting.
> 
> What am I missing?
> 
> /Dick
> ᐧ
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

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

Re: [OAUTH-WG] Android App Links (AKA Universal Links)

[Tim Cappalli]

Here’s the OSW recording on app2app.

https://www.youtube.com/watch?v=vktyY5CXwjg


From: OAuth 
Date: Tuesday, November 3, 2020 at 14:14
To: Joseph Heenan , George Fletcher 
Cc: oauth 
Subject: Re: [OAUTH-WG] Android App Links (AKA Universal Links)
Thanks Joseph.

George Fletcher ran a great session on the topic at the last IIW as well.

George: do you have a link?

[https://mailfoogae.appspot.com/t?sender=aZGljay5oYXJkdEBnbWFpbC5jb20%3D=zerocontent=26f11e54-06bb-45f0-ba83-5ff627ed5579]ᐧ

On Tue, Nov 3, 2020 at 11:09 AM Joseph Heenan 
mailto:jos...@authlete.com>> wrote:
Hi Dick

I didn’t attend the call so don’t know the background of this and the exact 
situation, but the general problem is mostly where the Authorization Server’s 
app is *not* installed. In that case Android falls back to much weaker 
mechanisms that allow other apps to get a look in. App links also aren’t 
consistently supported across all commonly used android browsers which causes 
further problems.

In general to do app2app oauth redirections securely on Android it’s necessary 
for both apps to fetch the /.well-known/assetlinks.json for the url they want 
to redirect to, and verify that the intent the app intends to launch to handle 
the url is signed using the expected certificate. Web2app flows are trickier, 
on both iOS and on Android. There were lengthy discussions on at least the 
Android case at OAuth Security Workshop this year (recordings available).

Joseph



On 20 Oct 2020, at 00:09, Dick Hardt 
mailto:dick.ha...@gmail.com>> wrote:

Hey Vittorio

(cc'ing OAuth list as this was brought up in the office hours today)

https://developer.android.com/training/app-links

An app is the default handler and the developer has verified ownership of the 
HTTPS URL. While a user can override the app being the default handler in the 
system settings -- I don't see how a malicious app can be the default setting.

What am I missing?

/Dick
[https://mailfoogae.appspot.com/t?sender=aZGljay5oYXJkdEBnbWFpbC5jb20%3D=zerocontent=753a4eae-4c54-40f0-a603-09ea6cdfe434]ᐧ
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

Re: [OAUTH-WG] New Version Notification for draft-meyerzuselhausen-oauth-iss-auth-resp-01.txt

[Takahiko Kawasaki]

It sounds that the Security Considerations section or somewhere appropriate
should have a paragraph like below.

When an authorization response includes a JWT whose `iss` claim represents
the issuer identifier of the authorization server, the `iss` claim can be
used as a substitute for the `iss` parameter. Therefore, such authorization
response does not have to have the `iss` parameter outside the JWT
separately. Examples of such JWTs include the value of the `id_token`
parameter in OIDC and the value of `response` parameter in JARM.

Taka

On Tue, Nov 3, 2020 at 10:46 PM Joseph Heenan  wrote:

> I agree, it is in redundant in the JARM case.
>
> I find the text in
> https://www.ietf.org/archive/id/draft-meyerzuselhausen-oauth-iss-auth-resp-01.html#name-security-considerations
> (the 4th paragraph where JARM & JWTs) are mentioned a bit confusing - I
> think it would be good to say something along the lines of:
>
> Although integrity protection is not necessary to prevent mixup, any
> authorization response method that includes a JWT with an ‘iss' (for
> example, JARM or OIDC hybrid flow) will prevent the attack (assuming the
> client is validating the iss).
>
>
> I’m not entirely sure I understand what "MUST NOT allow multiple
> authorization servers to return the same issuer identifier during
> registration” means as I don’t think https://tools.ietf.org/html/rfc7591
> returns the issuer?
>
> It might be clearer to say something like “When
> https://tools.ietf.org/html/rfc8414 is used the client MUST implement the
> validation described in https://tools.ietf.org/html/rfc8414#section-3.3.
> When authorization server details can be manually configured in the client,
> the client must verify that all issuer values are unique.” (Or at least
> something along those lines, I’m sure my wording can be improved. But if
> the client is correctly implementing rfc8414 or OIDC discovery [and does
> not have any manually configured authorization servers] then there’s no
> requirement for any further checks that the issuer is unique.)
>
> Joseph
>
>
> On 3 Nov 2020, at 07:01, Vladimir Dzhuvinov 
> wrote:
>
> This can potentially occur. If JARM is used "iss" becomes redundant. To me
> JARM is an "enhanced" iss.
>
> If both are included a sensible client should make sure the iss and the
> JARM iss match.
>
> My suggestion is to not require iss when a JARM is present, but in case
> both do occur to have the client check both.
>
> Vladimir
> On 02/11/2020 22:34, Takahiko Kawasaki wrote:
>
> Hi Karsten,
>
> The specification mentions JARM. Does this specification require the iss
> response parameter even when JARM is used? That is, should an authorization
> response look like below?
>
> HTTP/1.1 302 Found
> Location: https://client.example.com/cb?response={JWT}={ISSUER}
>
> Or, can the iss response parameter be omitted when JARM is used?
>
> A small feedback for the 3rd paragraph in Section 4:
> s/identifes/identifies/
>
> Best Regards,
> Taka
>
>
> On Tue, Nov 3, 2020 at 3:13 AM Vladimir Dzhuvinov 
> wrote:
>
>> Thanks Karsten, looks good to me now, no further comments.
>>
>> Vladimir
>> On 02/11/2020 09:54, Karsten Meyer zu Selhausen wrote:
>>
>> Hi all,
>>
>> Daniel and I published a new version of the "iss" response parameter
>> draft to address the feedback from the WG.
>>
>> Changes in -01:
>>
>>- Incorporated first WG feedback
>>- Clarifications for use with OIDC
>>- Added note that clients supporting just one AS are not vulnerable
>>- Renamed metadata parameter
>>- Various editorial changes
>>
>>
>> We would like to ask you for further feedback and comments on the new
>> draft version.
>>
>> Best regards,
>> Karsten
>>
>>  Forwarded Message 
>> Subject: New Version Notification for
>> draft-meyerzuselhausen-oauth-iss-auth-resp-01.txt
>> Date: Sun, 01 Nov 2020 23:31:42 -0800
>> From: internet-dra...@ietf.org
>> To: Karsten Meyer zu Selhausen 
>> , Karsten zu Selhausen
>> 
>> , Daniel Fett 
>> 
>>
>>
>> A new version of I-D, draft-meyerzuselhausen-oauth-iss-auth-resp-01.txt
>> has been successfully submitted by Karsten Meyer zu Selhausen and posted
>> to the
>> IETF repository.
>>
>> Name: draft-meyerzuselhausen-oauth-iss-auth-resp
>> Revision: 01
>> Title: OAuth 2.0 Authorization Server Issuer Identifier in Authorization
>> Response
>> Document date: 2020-11-01
>> Group: Individual Submission
>> Pages: 10
>> URL:
>> https://www.ietf.org/archive/id/draft-meyerzuselhausen-oauth-iss-auth-resp-01.txt
>> Status:
>> https://datatracker.ietf.org/doc/draft-meyerzuselhausen-oauth-iss-auth-resp/
>> Html:
>> https://www.ietf.org/archive/id/draft-meyerzuselhausen-oauth-iss-auth-resp-01.html
>> Htmlized:
>> https://tools.ietf.org/html/draft-meyerzuselhausen-oauth-iss-auth-resp-01
>> Diff:
>> https://www.ietf.org/rfcdiff?url2=draft-meyerzuselhausen-oauth-iss-auth-resp-01
>>
>> Abstract:
>> This document specifies a new parameter "iss" that is used to
>> explicitly include the issuer identifier of 

Re: [OAUTH-WG] Android App Links (AKA Universal Links)

[George Fletcher]

I sent in some notes but I don't have a link for the recording. I don't 
believe the recordings were being kept much past the end of the 
conference. I'm pretty sure I heard that the recordings would be removed 
after N days (I don't remember what N was stated as:)


Joseph explanation is better than I could have given and matches my 
understanding as well.


Thanks,
George

On 11/3/20 2:13 PM, Dick Hardt wrote:

Thanks Joseph.

George Fletcher ran a great session on the topic at the last IIW as well.

George: do you have a link?

ᐧ

On Tue, Nov 3, 2020 at 11:09 AM Joseph Heenan  wrote:


Hi Dick

I didn’t attend the call so don’t know the background of this and the
exact situation, but the general problem is mostly where the Authorization
Server’s app is *not* installed. In that case Android falls back to much
weaker mechanisms that allow other apps to get a look in. App links also
aren’t consistently supported across all commonly used android browsers
which causes further problems.

In general to do app2app oauth redirections securely on Android it’s
necessary for both apps to fetch the /.well-known/assetlinks.json for the
url they want to redirect to, and verify that the intent the app intends to
launch to handle the url is signed using the expected certificate. Web2app
flows are trickier, on both iOS and on Android. There were lengthy
discussions on at least the Android case at OAuth Security Workshop this
year (recordings available).

Joseph


On 20 Oct 2020, at 00:09, Dick Hardt  wrote:

Hey Vittorio

(cc'ing OAuth list as this was brought up in the office hours today)

https://developer.android.com/training/app-links

An app is the default handler and the developer has verified ownership of
the HTTPS URL. While a user can override the app being the default handler
in the system settings -- I don't see how a malicious app can be the
default setting.

What am I missing?

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





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