Subject: Re: [Ace] Review on draft-ietf-ace-dtls-authorize-00

From: Olaf Bergmann <[email-masked]>
Date: Mon, 03 Jul 2017 22:21:22 +0200

Jim,

Thank you very much for the detailed comments. Please see responses
inline. I have uploaded version -01 with minor edits listed at the end
of your message. (Unfortunately, I did not yet have time to propose
changes for the non-editorial comments.)

Jim Schaad <[email-masked]> writes:

> I have some comments on this draft that I have gotten from implementation
> attempts.
>
> Major Issues:
>
> Section 2 talks about looking things up in the resource directory, but it
> does not say what one would be looking for.  Is this material which should
> be in the generic document?

You are right, this is generic enough to go into the framework. There
had been a proposal for this in an earlier version of this document [1],
but this has been lost in the process. Maybe we can revive that somehow.

[1] https://tools.ietf.org/html/draft-gerdes-ace-dcaf-authorize-04#section-9

> Section 2 - I see a potential interop problem w/ the MAY about
> transferring
> the access token or PSK.  Does a client try it and if it does not work
> do it
> the other way or is it always going to post unless it has some external
> indicator that it can take the "shortcut" method?

My understanding is that the POST to /authz-info would be MTI as this
seems to be required by the framework. And yes, this would mean that the
"shortcut" (= sending the token in the psk_identity) requires some
external knowledge or trying.

> Section 2.1 - I do not understand why this is not in the mail document
> rather than in this profile.

Good point. The main document's authors are aware of that and my
understanding is that this will go into that document. 

> Section 2.1 - The list of three items seems to be overly restrictive
> on what
> is allowed.  I believe that you are missing the case of no token
> because no
> token is needed (which would apply to /authz-info as well).  You have
> previously stated that going to /.well-known/core may be something that is
> desirable - either that or I completely miss understood what was being
> said
> above.

You may be correct: Requests for resources that are available without
authorization (as /.well-known/core usually is), would not be possible
when following this list. The first sentence of Section 2.1 should have
made clear that this applies only to resources that are to be
protected. Maybe this should be rephrased.

> Section 2.2 - I do not see the AS_Info map defined anyplace.  Am I missing
> something?

There had been a CDDL [2] which needs to be put back in, sorry for that.
[2] https://tools.ietf.org/html/draft-gerdes-ace-dcaf-authorize-04#appendix-A

> Section 2.1 - I am not sure - is the case of no valid access token
> supposed
> to cover cases where the token has expired?  Are there other cases
> that one
> needs to think about here?  Would it not be better to close the DTLS
> connection in the event that the last valid token expires?

"no valid access token" would cover these cases:

1. expired access token,
2. no token (but required for protected resource), and
3. rogue token.

Indeed, when a DTLS session already exists, it could make sense for an
entity to keep the connection, e.g., when it initially had the role of
RS and now uses the very same DTLS session as CoAP client for
communication with the same peer.

> Section 2.1 - You do not state if an AS_Info map should be returned
> for all
> three cases of failures.  I assume that it should be, but at the current
> level of information it might not be totally useful.

Yes, the intention was to return AS Info in all these cases. Why would
this not always be useful?

> Section 2.2 - You might want to differentiate on the setoff AS_info fields
> that would be returned in an unsecured vs secured channel.  That is, if I
> have a DTLS connection and try to do an operation that fails - then more
> info could be returned as it is not generally available.

Okay, this makes sense.

> Section 2.2. - I have no idea how to use this nonce value so that it
> ends up
> in the access token.

I do believe that the Client-to-AS request needs a mechanism to convey
this nonce.

> Section 2.3 - I have no idea what item #3 is supposed to be saying.
> How can
> an RS determine if it is the destination under normal circumstances?

This would be trivially true in a point-to-point communication
relationship because RS would be the only entity that can decode the
message. In group communication or scenarios where intermediaries are
involved this is would be a crucial requirement.

> Section 3 - I am not sure that the Note text really makes any sense.
> If the
> client implements Edwards rather than classic EC curves this makes no
> sense
> to offer.  

The intention was to have a reasonable mandatory-to-implement
ciphersuite. Are you suggesting to not specify any mandatory cipherwuite
for RPK mode?

> Section 4.1 - the psk_identity field in TLS is a binary field - why do the
> base64 encoding - need to justify this.

The problem is the psk_identity must be valid UTF-8 which we cannot
guarantee when sending raw CBOR data.

> Also the current text means
> that I
> suddenly have three different things that can be in this field.  This
> is not
> the type of thing hat would make me happy.  Where you want me to do
> this is
> not the easiest place to suddenly do the processing needed to validate
> a new
> access token.

I understand your concern. Need to think more about this.

> Section 4.1 - I don't understand what the text around COSE_Encrypt is
> supposed to be doing.  It makes little sense to me but I have not tried to
> think about it deeply.

The idea was to have a mechanism for RS to derive a session key from the
access token and a shared key between AS and RS. I personally think this
is the most secure mechanism to transfer the session key.

> Section 4.2 - I don't know that a reference to 5746 is going to be any
> good
> long term.  

Can you elaborate why this might not be good?

> Section 4.2 - need to distinguish between cases where the permissions are
> update vs where the key is updated.  The former SHOULD NOT require a new
> session to be established.

Correct.

> Section 5.1 - I am not sure what this means.  I assume that this text
> should
> say that a client should only deal with an AS for which it has a security
> relationship.

Interesting. This would be an important design decision.

> Note that it might be an idea to be able to copy the AS
> from
> the RS into the AS request in the event that they do not match so that
> four
> corner authorization can be supported.

Yes, I suppose this would be the preferable way to go forward.

> Minor Issues:
>
> * I would stop the PSK and RPK paragraphs in the introduction so that they
> are in the same order as in sections 3 and 4.

Done.

> * In the introduction - clean up the last two paragraphs.  The reference #
> is off as is the extra line in the Note

The reference now is fixed for the version -06 of draft oauth-authz.

Regarding the note, I am not sure how this can be fixed. As this note is
temporary in nature, I will leave it as is for now.

> * Remove the mention of OSCOAP in section 4 - If you want to say another
> profile exists, do it in the introduction.

Okay, I have removed it for now.

Grüße
Olaf

---

From: Ludwig Seitz <[email-masked]>
Date: Mon, 24 Jul 2017 08:37:19 +0200

Hello, I'm back from my holidays, sorry for the delay in commenting. 
Please find additional comments inline
(and thanks to Jim for reviewing!)

/Ludwig

> I do believe that the Client-to-AS request needs a mechanism to convey

You can just add a new parameter to the Client-to-AS request, but 
currently no such parameter is defined. You can also add a new claim in 
the token that contains this nonce.

Do you feel this would be necessary base functionality in 
draft-ietf-ace-oauth-authz? Otherwise a short draft adding these 
parameters/claims and explaining their use would seem best.

> I understand your concern. Need to think more about this.

We can have the following 3 things in psk-identity:

1. A psk-identity
2. A BASE64 encoded kid
3. A BASE64 encoded access token

So my code currently checks the following:

1. Do we have a key with an identifier matching the raw content of 
psk-identity?

1.1. Does psk-idenitity decode to a CBOR map? If no return error

2. Does the map contain a kid
	if yes do we have a key for that
		if no return error
		if yes use that key
3. Does the map contain an access token?
	if yes process ...

I think we might be able to cut out item 2.

> Can you elaborate why this might not be good?

AFAIK the TLS WG is not considering to implement this extension for TLS 1.3

> Interesting. This would be an important design decision.

I assume it would be hard for a client to get an access token from an AS 
with which it does not have a security relationship. Why would an AS 
give out an access token to a client it doesn't know?
My take on the AS info is that it just helps the client to pick the 
right AS from a list of previously known AS's.

/Ludwig

-- 
Ludwig Seitz, PhD
Security Lab, RISE SICS
Phone +46(0)70-349 92 51