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 protected]> 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 _______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
