Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow reverse flow and sending the token in EAD2 #5

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

chrysn
Copy link

@chrysn chrysn commented Mar 4, 2024

Coming out of https://www.ietf.org/archive/id/draft-amsuess-core-resource-directory-extensions-10.html#name-ace-edhoc-profile, I'd like to propose that the token can also be sent in EAD2.

This present PR is incomplete as it only states this in one place without syncing the rest of the document; I'll need to come back to this.

As long as no CoAP role reversal happens, this will be used with the reverse message flow of EDHOC; if we go with this, I'll add more changes:

  • C (the responder) may not have received identifying information about the RS through EDHOC. (Granted, the same is true when doing a plain POST). Unless it has not received any out of band, it may need to use a token that has a group audience, and compare the precise ID_CRED_I that comes back to the rs_cnf2 that was part of its token response.

  • Add bit more explicit stating that reverse flow is allowed. That will likely need to talk briefly about vulnerable identities in that context, with two options:

    • C already knows precisely which RS to talk to. Then AS can create a symmetrically encrypted token, so it doesn't matter if an active attacker can obtain it.
    • C does not already know, and takes a group token. Group tokens are notoriously hard to encrypt (yada yada group key management), but the main information in the token is that C is allowed to do something (in the motivating example, serve as an RD), and we've chosen reverse flow because C has the less sensitive identity, and that's usually OK to reveal to an active attacker.

@gselander
Copy link
Collaborator

Thanks @chrysn! Too late for IETF 119 submission but good start for discussion. Would be good to sketch the use case / trust model to see what is the relevant order of steps. E.g. why not use EAD_4 instead (besides less optimal), in which case the initiator is authenticated and access token becomes encrypted for known recipient.

@chrysn
Copy link
Author

chrysn commented Mar 5, 2024

ad EAD4: If by message 2 the initiator has not presented something credible, the advantage of protecting the more vulnerable identity is lost. (Else, they could go with the forward message flow). There is a good case for that in 2-stage authentication/authorization, though. (Like, when ID_CRED_2 is a verbatim "short" certificate attesting that its subject is part of the domain with some identity, and then the token adds authorizations).

Using EAD4 would beg the question of whether for that case, using the EDHOC option with message 4 makes sense; pinging @marco-tiloca-sics as AIU the main corresponding person on that document.

@chrysn
Copy link
Author

chrysn commented Mar 19, 2024

See #8 for more high-level discussion.

As that indicates that some more guidance would be needed, I'm setting this as "ready for review", because it lays the groundwork for a more comprehensive solution to 8.

@chrysn chrysn marked this pull request as ready for review March 19, 2024 13:31
@gselander
Copy link
Collaborator

There is a separate section about reverse flow in -06. Does that replace the need for this PR?

@gselander
Copy link
Collaborator

Comment from Marco: Still remains to add motivation and pros and cons of forward/reverse flow.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants