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
On 2017-07-03 22:21, Olaf Bergmann wrote:
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.
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.
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.
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.
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?
AFAIK the TLS WG is not considering to implement this extension for TLS 1.3
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.
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
_______________________________________________
Ace mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ace
