[Openid-specs-ab] [Bitbucket] Issue #851: Messages 2.1.2.1 - Clarify that "none" is not an acceptable signature algorithm (openid/connect)

Thu Jun 27 03:09:46 UTC 2013

My preference is for 1 - always sign the ID token.

Vladimir

--
Vladimir Dzhuvinov : www.NimbusDS.com : vladimir at nimbusds.com

-------- Original Message --------
Subject: Re: [Openid-specs-ab] [Bitbucket] Issue #851: Messages 2.1.2.1
- Clarify that "none" is not an acceptable signature algorithm
(openid/connect)
From: Mike Jones <Michael.Jones at microsoft.com>
Date: Thu, June 27, 2013 12:10 am
To: Brian Campbell <bcampbell at pingidentity.com>
Cc: "openid-specs-ab at lists.openid.net"
<openid-specs-ab at lists.openid.net>

   What do others think?  I understand what Brian is saying but I’m
not sure that we want to give OPs permission to ever not sign ID Tokens.

 The choices before us seem to be:
 1.  Clarify that “none” is never an acceptable “alg” value.
 2.  Change the specs to say that “none” may be supported by some
OPs and limiting the circumstances under which they may do so.
 3.  Change the specs to say that OPs are required to support “none”
under specific circumstances.

 I think I could personally live with either 1 or 2 and prefer 1.  I
don’t think I can agree for us to do 3.

 I think that 1 is the most straightforward thing to do and doesn’t
impose any significant implementation burden.  Remember that as a design
philosophy, we’re consciously moving complexity away from clients and
pushing it to servers, when such tradeoffs arise.  This seems like such
a case.  By requiring that OPs always sign the ID tokens they issue,
Clients can always decide to check the signature.  They don’t have to
deal with the case where they might not be able to check a signature
because none is present.  And it’s really not hard for the server to
just sign it.  So I don’t see any practical value in not signing the
token.

 But again, it would be good to hear from a lot of other people on this
issue.

                                                                 -- Mike

 From: Brian Campbell [mailto:bcampbell at pingidentity.com] 
 Sent: Wednesday, June 26, 2013 2:47 PM
 To: Mike Jones
 Cc: openid-specs-ab at lists.openid.net
 Subject: Re: [Bitbucket] Issue #851: Messages 2.1.2.1 - Clarify that
"none" is not an acceptable signature algorithm (openid/connect)

  On Tue, Jun 25, 2013 at 10:07 AM, Mike Jones
<Michael.Jones at microsoft.com> wrote:
   It’s a breaking change because clients currently conforming to
Messages that always verify the ID Token signature would break if no
signature is contained in the ID Token.

And any such client would already be registered or configured for one of
the other algorithms and wouldn't receive a token with the "none"
algorithm. That breaking change situation wouldn't occur. 

   “none” is not a signature algorithm.  JWS and JWA are clear that
this results in an unsigned, “plaintext JWS”, and JWT is clear that
this results in a “plaintext JWT” – not a signed JWT.  Messages
requires that ID Tokens be signed.  Sending an unsigned ID Token
doesn’t fulfill this requirement.

    This bug is about making the current meaning of the text – that ID
Tokens must be signed – even more clear, so that developers who
aren’t reading JWS closely won’t make the mistake of thinking that
just because “none” can be used to create a JWS, that the resulting
JWS is signed.  (Apparently you were one such developer – making the
need for this clarification all the more evident. J)

I guess we agree that it's not at all clear as it currently written. Yes
"none" is different than the other algorithms but I'd say that line of
reasoning is a slippery slope.  Messages 2.1.2.1., for example, says
that the ID Token must be signed thereby providing non-repudiation, "ID
Tokens MUST be signed using JWS [JWS] and OPTIONALLY both signed and
then encrypted using JWS [JWS] and JWE [JWE] respectively, thereby
providing authentication, integrity, non-repudiation, and optionally,
confidentiality, per Section 9.13."  But the HMAC algorithms aren't
signature algorithms either and certainly don't provide non-repudiation.
So they shouldn't be acceptable algorithms either, right? 

 I realize it's probably futile to argue but what I'm saying is that it
is a reasonable thing to use "none" when the token is sent only via the
TLS protected back-channel. And given that I'm "one such developer,"
I've now got publicly released software that does allow "none" in that
situation where it does make sense. 

   From: Brian Campbell [mailto:issues-reply at bitbucket.org] 
 Sent: Tuesday, June 25, 2013 7:58 AM
 To: Mike Jones
 Subject: Re: [Bitbucket] Issue #851: Messages 2.1.2.1 - Clarify that
"none" is not an acceptable signature algorithm (openid/connect)

       Brian Campbell commented on issue #851: 
     Messages 2.1.2.1 - Clarify that "none" is not an acceptable
signature algorithm 
     I disagree. 
 How would that be a breaking change? If a client is currently
configured/registered for RS/EC/HS signature, how would allowing none as
a different option be a breaking change? 
 Our implementation currently does allow none as an option (it will only
send such an ID Token via the back-channel). Which is, I'll argue, a
perfectly reasonable interpretation of what's been written. So
explicitly disallowing it is a breaking for us. 

     View this issue or add a comment by replying to this email. 

        Unwatch this issue to stop receiving email updates. 

_______________________________________________
Openid-specs-ab mailing list
Openid-specs-ab at lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs-ab