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

From: Jim Schaad <[email-masked]>
Date: Wed, 21 Jun 2017 14:05:13 -0700

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?

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?

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

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.

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

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?

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.

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.

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

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?

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.  

Section 4.1 - the psk_identity field in TLS is a binary field - why do the
base64 encoding - need to justify this.  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.

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.

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

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.

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.  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.

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.

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

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

Jim