[security-dev] Implementing JSON Security

[Anil Saldhana]

Bill, I asked Axel Nennker (T-Mobile Germany) who is working on JOSE for 
many months now.
Here is his reply:

==================
I think S/MIME is good enough if your communication partner knows how to 
handle it and you are in the position to choose. And S/MIME is more 
mature than JW*. I am sure S/MIME implementation had a bunch of 
interoperability issues in the first year(s).

The problem is that you don't always have a choice as a developer. If 
you are programming the client for a specific API like OpenID Connect 
than you have to implement whatever the server understands.
Today everybody is stuffing parameters into JSON objects. If you want 
end to end security it is easy to put all your request parameters into a 
json structure, sign/encrypt it for the intended recipient and send it out.
It is true that this tends to reinvent the wheel for some use cases and 
maybe the new security is all but theater because the eager programmers 
in that hot startup are inventing an insecure protocol although they are 
using "secure" building blocks. Some will reinvent SSL and get it wrong.
So the answer is not easy.
I think application servers/frameworks should support jsoncrypto but 
some education of developers is needed. But this is true with all 
crypto. You can use it wrongly.

There was a long discussion on the JOSE mailing list about a 
vulnerability in a library that used my code. The same questions arose. 
My code provides building blocks but they were put together in such a 
way that an attacker could launch a Bleichenbacher attack against the 
server. There was no way for my code to prevent or detect this attack.

Coming back to the S/MIME topic. Currently my implementation just allows 
to encrypt and integrity protect one chunk of data. If you have a big 
plaintext and want to send it encrypted/signed in chunks then there is 
currently no method to do this in jsoncrypto. You have to protect each 
chunk individually. If I finish the Cipher API then this would 
automatically work. So in that big-file case you might want to use 
S/MIME (currently).
======================================


On 08/03/2012 02:26 PM, Anil Saldhana wrote:
> Bill, I agree on the S/Mime part.
>
> But the challenge is we cannot control what the clients use. If they use
> JSON Web Encryption and JSON Web Signatures as their payload interacting
> with a JAX-RS implementation, then you will fall short.
>
> JWE and JWS are being standardized at IETF along with OAuth2. JSON Web
> Token (JWT) is one of the prominent tokens in use with OAuth2. Of course
> Eran complained loudly about JWT.
>
> On 08/03/2012 01:54 PM, Bill Burke wrote:
>> Also multipart/signed or a combination of multipart/signed and encrypted
>> is supported as well.  I've tried it out in python as well.  So, JSON is
>> not required as a payload and you can sign or encrypt basically anything
>> you want.
>>
>> On 8/3/12 2:50 PM, Bill Burke wrote:
>>> Looks like you're encrypting the whole document?  Why not use S/MIME
>>> multipart/encrypted?
>>>
>>> http://docs.jboss.org/resteasy/docs/2.3.4.Final/userguide/html/ch38.html
>>>
>>> On 8/3/12 2:10 PM, Anil Saldhana wrote:
>>>> Last few hours, I prototyped the outgoing json payload encryption that
>>>> is described here:
>>>> https://docs.jboss.org/author/display/SECURITY/Securing+JAX-RS+Payload
>>>>
>>>> On 08/02/2012 11:28 AM, Bill Burke wrote:
>>>>> So why are you wasting your time with this?
>>>>>
>>>>> On 8/2/12 12:26 PM, Anil Saldhana wrote:
>>>>>> If Jackson needs to implement JSON security, they will have to code it.
>>>>>> The pragmatic thing for Jackson would be to just incorporate this teeny
>>>>>> library via maven dependency.
>>>>>>
>>>>>> On 08/02/2012 11:24 AM, Bill Burke wrote:
>>>>>>> FYI, again, unless this works with Jackson, the de facto JSON parser,
>>>>>>> you're probably not going to have many people taking advantage of this
>>>>>>> work...
>>>>>>>
>>>>>>> On 8/2/12 12:20 PM, Anil Saldhana wrote:
>>>>>>>> The German Researcher Axel Nennker created a separate project
>>>>>>>> http://code.google.com/p/jsoncrypto/. He has given me commit rights so I
>>>>>>>> can mavenize his project.
>>>>>>>>
>>>>>>>> On 07/31/2012 10:15 AM, Anil Saldhana wrote:
>>>>>>>>> I created a wiki article.
>>>>>>>>> https://docs.jboss.org/author/display/SECURITY/JSON+Security
>>>>>>>>>
>>>>>>>>> Will be adding more examples to this article.
>>>>>>>>>
>>>>>>>>> On 07/30/2012 11:22 AM, Anil Saldhana wrote:
>>>>>>>>>> Hi All,
>>>>>>>>>>              as you know currently IETF is working on securing JSON.  The drafts
>>>>>>>>>> are all available here:
>>>>>>>>>> http://datatracker.ietf.org/wg/jose/
>>>>>>>>>>
>>>>>>>>>> So last week, I implemented at least the bare minimum we require to
>>>>>>>>>> secure JSON.  But encryption is tricky given that there are a lot of
>>>>>>>>>> algorithms that are not yet available in the JDK implementation but are
>>>>>>>>>> available via the BouncyCastle project.
>>>>>>>>>>
>>>>>>>>>> Look at the supported table:
>>>>>>>>>> http://www.ietf.org/mail-archive/web/jose/current/msg00928.html
>>>>>>>>>>
>>>>>>>>>> While I was doing my implementation, I found out that there is a German
>>>>>>>>>> researcher working on a project called xmldap.org and has implemented
>>>>>>>>>> the drafts fully. He has been doing this for months. His license is MIT
>>>>>>>>>> style.  I have requested him to create a separate independent project
>>>>>>>>>> for JOSE so everybody can reuse his work, rather than create umpteen
>>>>>>>>>> implementations.  He has agreed to work with me.
>>>>>>>>>> http://ignisvulpis.blogspot.com/2012/06/ecdh-es-for-json-web-encryption.html
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>> Anil
>>>>>>>>>>