Hi Hannes
On 27/02/13 08:54, Hannes Tschofenig wrote:
Hi Sergey,
good that this issue got clarified.
Regarding:
By the way, should the server be able to enforce the use of MAC as opposed to
having a client preferring it with its audience info ? If the client does not
understand it then it does not have the capabilities to work with this specific
server.
Currently, the authorization server decides about the use of a certain token
type. The audience field is used to allow the client to tell the server which
resource server it wants to talk to. This is of value not only for this
specification but also for the bearer token specification. In this
specification the resource server uses this audience field for selecting the
appropriate key to encrypt the access token. If the client is tricked in
sending the access token to a different resource server then that server will
not be able to decrypt the access token and will not be able to retrieve the
session key. Consequently, it will not be able to impersonate the client
towards another resource server.
Thanks for the explanation, I should've read better, 'audience' is a
useful attribute.
What confused me was this text: "Authorization servers issue MAC Tokens
based on requests from clients." - it kind of reads to me that the
clients drive whether it is MAC or some other token type is issued in
exchange for a grant while I'd expect the AS administrators deciding on
what sort of token type is used.
As for "MUST" and audience - might it make sense to replace it with
SHOULD or RECOMMENDED ? I wonder if some issues like port number of
individual resource servers comprising the bigger resource server
application, etc, might make it difficult to use 'audience' - not sure
if it of real concern or not :-)
Thanks, Sergey
Ciao
Hannes
On Feb 26, 2013, at 2:49 PM, Sergey Beryozkin wrote:
Hi Again
On 26/02/13 12:36, Sergey Beryozkin wrote:
Hi Hannes
On 25/02/13 12:46, Hannes Tschofenig wrote:
Hi all,
I just submitted an updated version of the
draft-ietf-oauth-v2-http-mac-03.txt.
It definitely has more interesting content (about architecture, session
keys, etc) - this is really useful IMHO.
What I'm not really understanding is why a 2-way TLS transport for the
session key is not even considered.
Instead this uber-complex (in the context of this spec, IMHO) JWT thing
is there once again. I appreciate why it may be the case, primarily to
do with reusing the work done around JWT and having some
common/recommended access token representation, but disallowing a basic
bearer token be 'enhanced' with MAC over two-way TLS seems like not
ideal at all IMHO.
To be honest, I'm not sure why would anyone use JWT+MAC instead of just
JWE, in cases when people are really comfortable with doing JWT. I guess
we may be talking now about better security characteristics, but this
will help a very limited audience as compared to a wider one which can
use Bearer+MAC over 2-way TLS, straightforward, very cheap effort to get
started.
Oops, I've misread, I think I did, I was reading a Session Key Transport to
Resource Server section [1] where using JWT seems just OK, while a transport to
the client section [2] does not enforce the use of JWT.
Sorry for a noise :-)
By the way, should the server be able to enforce the use of MAC as opposed to
having a client preferring it with its audience info ? If the client does not
understand it then it does not have the capabilities to work with this specific
server.
Thanks, Sergey
[1] http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-03#section-4.2
[2] http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-03#section-4.1
just my 2c
Thanks, Sergey
I would like to point out that this is **discussion input** -- not
agreed content. Anything in the document is subject to change!
You also may notice that there are a few questions in the writeup.
I was trying to more specific about some of the design aspects that
folks had proposed during the last few months.
I have also re-submitted the draft-tschofenig-oauth-hotk, which
includes a TLS and a JSON-based solution approach.
In general, the open questions still seem to be related to
* Key distribution: What should be described in a document? What is
mandatory to implement?
* Selective header field protection: This is something that was
brought forward in discussions and I have included a proposal of how
this could look like.
* Channel Binding: Functionality is also included to deal with
man-in-the-middle attacks against TLS. There are, however, two types
of channel bindings defined in RFC 5929. Are both needed? If not,
which one should be selected?
* Integrity protection and data origin authentication in both
directions: The current writeup allows the protection to be extended
to messages beyond the initial request. This also offers key
confirmation by the server and protection of any responses.
Writing the text I also noticed that I do not quite understand how
nested JWT documents are supposed to look like. For example, how do I
encrypt the mac_key carried inside the JWT plus add a signature of all
other fields? Currently, I have just encrypted the entire payload.
I hope to have some discussions prior to the IETF meeting so that we
have a more fruitful discussion at the face-to-face meeting.
Ciao
Hannes
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
