[Openid-specs-fapi] OpenID/FAPI alternative to draft-cavage-http-signatures

Thu May 9 16:22:52 UTC 2019

Anders

There was an alternative published by the oauth wg that was much better (ed by Justin Richer). 

The IETF community made it clear that such a draft would have high faulty error rate in the real world because of the nature of http. Too many things mess with http in every part of the internet stack. Just as smtp is messed with. 

Justins draft did however allow parties to negotiate specific url elements, headers to be signed and made caveats clear. 

Still it was no go. The position then was that the entire request semantics have to be encapsulated in some way. 

Security can be done by going underneath by leveraging mtls.  However if you want after the fact audit you have to go on top of http. 

This has the fundamental problem of blurring the separation between security layers and API design. 

Remember how awful SOAP was?

Btw. There was another interesting initiative in IoT called ATLAS. Application Transport LAyer Security. This solves part of the issue by encoding http and re-using key tls semantics to build that app layer integrity while keeping app layer logic unaffected. 

This is a hard problem that began with http. Don’t think its because people do not want it solved. 

If it is complex developers won’t use it, or worse they will do just enough to make it work with little care for security. 

Finally there is an argument to be made that with MTLS or TLS 1.3, most of the parties that may “optimize” content and break signatures will be cut out because proxies become impossible. If MTLS is present, I would feel better about http signing being error free because we would know the elements in the path cryptographically and can control how messages are modified. Eg an ingress controller adding headers. 

Phil

> On May 9, 2019, at 8:09 AM, Takahiko Kawasaki via Openid-specs-fapi <openid-specs-fapi at lists.openid.net> wrote:
> 
> Dear Anders,
> 
> I read draft-cavage-http-signatures for the first time just now.
> 
> According to the specification, when a server receives a request, the server uses keyId to look up a public key whereby to verify the signature attached to the request. However, details of keyId are left to each implementation. Therefore, it is even possible for a server implementation to make all clients share one private key although it may sound ridiculous. Of course, such server implementation cannot distinguish clients from the signature.
> 
> If a server implementation wants to make each client use their own private key, the server implementation has to be able to look up a corresponding public key of each client from keyId. This implies that keyId has to be associated with information whereby for the server implementation to identify the client making the request and look up the client's public key. However, the specification does not define anything about how to identify a client from keyId and how to manage public keys of clients. So, if I were told to implement the specification, I would start from inventing my own rule for keyId.
> 
> In contrast, OpenID Connect already has infrastructure for (1) client identifiers (client_id in RFC 6749), (2) server-side key management (jwks and jwks_uri in OIDC Discovery), (3) client-side key management (jwks and jwks_uri in OIDC Dynamic Client Registration) and (4) signing and encryption rules (RFC 7515 to RFC 7519).
> 
> In the context of OAuth/OIDC/FAPI, I think there are three points where message integrity may be desired. The following are the three points.
> 
> 1. Connection between a client and an authorization endpoint of authorization server
> 2. Connection between a client and a token endpoint of authorization server
> 3. Connection between a client and a protected resource endpoint of resource server
> 
> For 1, Request Object (OIDC Core, Section 6) exists for message integrity of requests and JARM (JWT Secured Authorization Response Mode for OAuth 2.0) exists for message integrity of responses. If JARM is not supported, ID Token can be used as detached signature (FAPI Part 2, Section 5.1).
> 
> For 2, the combination of PKCE (RFC 7636) and mutual TLS with certificate-based client authentication (MTLS, Section 2) is probably enough, but my understanding may be wrong.
> 
> For 3, the combination of certificate-bound access tokens (MTLS, Section 3) and mutual TLS is probably enough, but my understanding may be wrong.
> 
> Therefore, it might be difficult to find imminent and strong need to officially adopt yet another specification for message integrity in the context of OAuth/OIDC/FAPI.
> 
> From an implementer's point of view, lack of the concept of client identifiers and key management infrastructure might be a kind of hurdle to discuss draft-cavage-http-signature deeply here in this FAPI Working Group although the specification seems great as a generic solution for HTTP message integrity.
> 
> Best Regards,
> Takahiko Kawasaki
> Authlete, Inc.
> 
> 
> 
> 
> 
> 2019年5月9日(木) 14:40 Anders Rundgren via Openid-specs-fapi <openid-specs-fapi at lists.openid.net>:
>> Dear Chair & List,
>> 
>> To me it looks close to ridiculous publicly downplaying https://datatracker.ietf.org/doc/draft-cavage-http-signatures/ without providing an alternative.
>> 
>> If nobody within the OpenID community is even interested in this matter, why the concern?
>> 
>> Please provide a plan on how to resolve this issue, or simply accept that https://datatracker.ietf.org/doc/draft-cavage-http-signatures/ is the de-facto standard for (at least) Open Banking.  The industry in general (as proven by this case) does not seems to have any major issues with de-facto standards.
>> 
>> If OpenID/FAPI intend to wait another year addressing this issue, the de-facto status will be cemented.  Personally I see no problems if that would be the case.  The authors also seem open to input.
>> 
>> sincerely,
>> Anders
>> _______________________________________________
>> Openid-specs-fapi mailing list
>> Openid-specs-fapi at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-fapi
> _______________________________________________
> Openid-specs-fapi mailing list
> Openid-specs-fapi at lists.openid.net
> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_mailman_listinfo_openid-2Dspecs-2Dfapi&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=aGhhJY89Ha0iunO6RpSAS5n1XDEcBwi9sk7dgPVyqCI&s=420qVD0d_gmIGn0CMjOLk1w_4Ov78sk5u-3lASunL5I&e=
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-fapi/attachments/20190509/eac29636/attachment-0001.html>