GNAP IETF-113

March 25, 2022 (all times Vienna local)

Protocol updates - Editors

presenter: Justin Richer

Issues closed, everything listed on GitHub.

Functional Changes (slide 7)
* Security Considerations
* Subject Identifier
* Keys
* Discovery
* Interaction
* Error Codes
* Token Management

User_code & user_code_uri
creates two user interaction modes
user_code_uri includes a short static URI, presumed to be able to be human / user typeable
should create different human/UI interaction modes

Should the "redirect_mode" be renamed? It doesn't just handle "redirects".

Would like to see more exercising / implemention on subject information response. More aligned with current SecEvent formats.

jhoyla: So I haven't read any of the drafts or anything, but with the confusion attacks, would it be possible to have a master key and then use a KDF to produce an independent key for each AS?
justin: can definitely use a KDF to derive a key; as long as the AS accepts the key. AS's could be in a federation and use a KDF to accept dervied keys.

Hackathon and implementation updates - Editors

presenter: Justin Richer

Aaron Parecki & Justin Richer did a bunch of hacking during the IETF-113 hackathon.

Goal was to make valid requests and exercise the user interaction and get valid tokens from the AS.

Not a lot of good libraries available to do GNAP, not surprising at this point. HTTP structured field libraries are very helpful. HTTP message structures from scratch is complex to write from scratch.

GNAP wasn't too complicated to implement once HTTP Message Signatures infrastructure are in place.

LIVE DEMO TIME

Justin's Demo:

https://gnap-c.herokuapp.com - if you want to follow along at home; be ready to use your mental JSON decoding to use this hackathon grade UI

https://gnap-as.herokuapp.com - there's the AS

Aaron's Demo:

question time

Jonathan Hoyland: The message format/signatures, do they include a message identifier, like "GNAP" so that these can't be used as an Oracle.
Justin: clients should not sign something that they aren't going to send; so it should be a problem there; just like TLS does
Jonathan: TLS does include a big hunk of text with TLS so that it can't be used this way, for this problem
Justin: Big HTTP message structure gets parsed into the thing to be signed, so it should be
Yaron: +1 signatures are relatively easy to write if you have a structured field library
Yaron: supports Jonathan's idea, should include distinguished string, like the JWT "@typ" field
[note taker out - the answer is now reading TINY text on the screen from an example]

Future work - Editors

presenter: Justin Richer

Yaron: I was going to ask if the protocol is ready to freeze, to allow researchers to focus on proofs/attacks. But if we're still changing the state machine, we're not ready. To be clear: I am supportive of that.
Justin: I think we're clarifying the state machine, but until this is well formalized and written down, we are not ready. It will also help, when it can be written down that formal analysis can be done, for developers. Some comparison between OAUTH2 linearity vs. GNAP state machine work flow, and how to restart interactions.

Key rotation proposal

Would like WG feedback.

Different mechanisms for each presentation type. Questions about flexibility of that, switching mechanisms etc are unresolved.

Extensions

JOSE

RS Draft

resource server: expired currently, but not forgotten

George Fletcher: proofing methods are key method specific. Should proofing methods be plugable and then JOSE method module becomes plugable.
Justin: that's exactly how it's written now. e.g. in the hackathon decided to only use the HTTP Message Sig method. Hopefully will become clear as better/more text on extensions gets written - what the requirements of the extension/method must provide, etc.
George: Is there a way when it hits that first single end point to find out what the supported proofing methods the AS supports
Justin: yes you can do a discovery request of the AS and it will respond. You can try your default method, and then get that response. Seeing 2 interaction approaches on that.

Ben Kaduk: You can have extensions be optional by default but with an explicit indication when a given extension is critical to comprehend.

Protocol embedding - Justin

presenter: Justin Richer

"no one ever runs a security protocol for the sake of running a security protocol"

Is this embedding something we care about?

This has been brought up twice, so people are thinking about.

Jonathan Hoyland: This looks like a place where you would use channel bindings (RFC 5056); could create an importer/exporter interface that would allow a principled way, especially for formal analysis
Justin: can you explain more
Jonathan: You need to define what the API is, but not tie that to the wrapping protocol, and then the channel bindings allow those channels to be defined. Then you can define the formal semantics on the GNAP
Justin: Yes, that's in one of the diagrams presented.

Yaron: I think this can become very complicated, very quickly and we should avoid it for now. The security analysis of doing this would be very complicated and the current state machine isn't settled. We shouldn't do this until V1 is done.

Justin: Leans toward not taking embedding on until v1 done either.

Open Mic

nothing heard

interim meeting will be planned.