# GNAP @ IETF112 Note Taker: Kathleen Moriarty ## Chair slides and overview - Yaron Code of Conduct review ## GNAP Editor Review of open issues Justin Richer presenting for editors Core-protocol-08 Resource-server-01 (not many updates since last meeting) Review some attacks and mitigations today Diff between 6-8 should be viewed to see updates from last meeting 32 pull requests (core draft) 3 pull requests (RS draft) Closed 55 issues Many changes suggested from the community, catching errors in text Changes outlined in slides and accessible in Git New major sections outlined - security, trust, and privacy Subject identifier and client instance identifier changes More details provided on the outlined changes. Trust model uses Promise theory - focuses on relationships between entities as opposed to the endpoints themseleves. Security considerations section has 25 subsections and editors would like to get more reviews and contributions to make sure it is as complete as possible. Organization work is in progress. Covers object and transport level considerations to have both integrity at the application layer and confidentiality at the transport layer. Bearer token protections included, even though may be obvious to many it will help with consistency between implementations and deployments. Cryto algorithms discussed and weaknesses pointed out if they are known. Authorization mixup server attack addressed that came up recently. Considerations included for attacks against other data structures, formats, and protocols used with GNAP added. Please read through and provide feedback to catch what is possible prior to publication. OAuth Security Workshop happening soon - free online event. Core GNAP protocol to be covered by Justin Fabien to present GNAP security analysis to get more review and analysis First time GNAP is part of the OAuth agenda, so it's a good opportunity and things can still be fixed by the larger community. OAuth Security Workshop https://barcamps.eu/osw2021/ Privacy Considerations: Followed RFC6973 for guidance Yaron: Summarized the talking points of presentation and asked about correlation between the 2 drafts. Justin: These sections have only been added to the core draft yet. It is expected that the RS draft will inherit much of the core draft, but additional content will be added specific to that draft. Tradeoffs of introspection for instance will be covered in RS draft. Symmetric cryptography: allowed but restricted Changes to User Handle - replaced with "subject information" opaque identifier to simplify protocol and maintain functionality Effort has been made to simplify the protocol, but maintain features using core capabilities where possible Client instance identifier under review to see if something similar can be done. Formal GNAP security analysis: Cuckoo token Attack reviewed, similarities to previous attacks and solutions discussed as well This attack works for key bound access tokens, token is replayed, no access the key is needed Client is tricked to using the token that is replayed Diagram is provided Editors have talked through this a bit with researchers and have proposed mitigations, not saying to do all of them Mitigation options outlined on slide 17 Olle Johansson is asking in chat about mitigations that also apply to OAuth Pedram Hosseyni asking how realistic is the second mitigation? Justin provided a response and will address this in the draft - use of different keys in MTLS as part of the security consideration. 307 Redirect attack covered - slide 18 Review and comments welcome to make the draft better. Editors proposal for work between now and next meeting Process issue backlog No solution for key rotation yet, important to do Probable direction presented - may not have one method Text will be proposed in the next few months - issues covered before Kathleen Moriarty asked about using ACME to help with the short lived certificates tying into the ACME client draft that provides an extension for new challenge types. Transparency log is used to help with short lived certificates in other use cases, including code signing certificates. The ACME client draft will be updated soon for another purpose to add OpenIdentity support. Here's a link: https://datatracker.ietf.org/doc/draft-moriarty-acme-client/ Look for updates soon and review appreciated. Yaron skeptical about interoperability profiles - profiles should be a separate draft Justin - the profiles may be by industry vertical Kathleen - note on adoption being higher when a protocol is simpler, but allows for extension points JOSE used in draft now in 2 places - slide 25 Should JOSe functions be in a separate draft? There are two other ways to address the same security properties, but there are tradeoffs. This will be discussed on list and security should be evaluated to see if multiple choices should be present. Yaron - if security is the same - then slim down the draft Implementation status section will be added to the draft. Core of protocol has remained quiet, so a good sign for stability of the protocol and to impplement. Open discussion: None ## Second presentation: Denis Pinkas Slides in datatracker meeting materials Technical difficulties with getting slides to display. Concerns with draft 8 with proposals to resolve concerns Differences between access models and proposed support of attributes should be added to the core document RBAC and Capability Based Access Controls (CBAC) Reasons provided on slide 4 Distinctions between rights and attributes Benefits discussed on slide 6 Questions trust relationships in slide 8 Denis asserts trust is binary, should be 0 or 1 Section 1.4 of draft 8, doesn't distinguish entities to a level where his assessment is that it is not complete Buid detection mechanism discussed on slide 15 EU legislation should be considered - slide 16 - GDPR, payments, etc. Chat of Meetecho includes sections to provide counter arguments to points made during presentation (pasted for completeness): fabien imbault See https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/134 for some discussion on this08:31:07 attributes were discussed in https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/24408:44:56 (and many other issues)08:45:06 Justin Richer There is not a precondition of the RS and AS knowing each other ahead of time, this was discussed here: https://github.com/ietf-wg-gnap/gnap-resource-servers/issues/8 (and a number of other issues)08:47:25 fabien imbault notice, choice, consent was discussed in https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/215, see last comment08:47:57 Justin Richer Opaque access tokens were discussed here: https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/14508:48:49 fabien imbault We have examples at the beginning of section 4, where RO != end-user08:48:58 Justin Richer We also have examples in the sequences and appendix where it's an automated process: https://www.ietf.org/archive/id/dra…ml#name-software-only-authorization and https://www.ietf.org/archive/id/dra…ol-08.html#name-no-user-involvement08:49:50 Another example where RO != End user is https://www.ietf.org/archive/id/dra…l#name-asynchronous-authorization-208:50:13 fabien imbault Section 4 of draft 8 does indicate those trust relationships08:50:20 Justin Richer Nothing in the draft assumes single factor authentication fabien imbault This was discussed at length in https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/32208:53:33 Justin Richer A subject identifier within an access token does not prevent it from being shared. different subject identifiers within an access token would be appropriate for the token model discussion in the RS draft, not within the core protocol08:55:43 (and none of these prevent token sharing)08:55:49 (Fabien: attributes were discussed in https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/244) Questions for Denis: Fabien: Issues have been discussed at length in the git repository. If there is additional discussion or arguments against decisions made, please speak up. It is clear from discussion and agreement that the disucssed items won't be included. Yaron requested additional comments and closed out the session.