November 2008


I had an interesting discussion with security experts inside Sun. The topic was OAuth and the way digital signature is defined there. One issue that was raised is the fact that (beside PLAINTEXT) only HMAC-SHA1 and RSA-SHA1 are defined in the specification when NIST recommends dropping those in place of SHA2 algorithms…
Why not using RSA-SHA256 at minimum and recommend to switch to the winner of the SHA3 competition whenever practical (granted, it’s gonna take a while…)?

Judging from the discussion on the OAuth mailing list prior to the release of the core spec, it seems that the main concern was the lack of support for, say, SHA256. This to me is a bit surprising for 2 reasons:
(1) I believe when creating a specification we should not settle for the lowest denominator but rather aim at a level of security that will last a reasonable amount time (between the time to implement and the time real deployments happen, security weaknesses will only get worse). This is even more important for specs, like OAuth, that seem promised to a bright & long future.
(2) It seems to me that RSA-SHA256 is available in most languages used in web development (Java, Perl, Php, python…).
So what am I missing?

Another issue is the lack of mandate for at least one signature mechanism and making the other ones optional. This certainly could cause interoperability issues as 2 implementations might be compliant to the specification and still not able to interoperate (i.e. if the consumer only supports a signature method that happens to be different from the one supported by the provider).

Hopefully, these issues will be addressed during the work done at IETF, now that the spec is headed there. More to come as I deep dive in OAuth and discuss this out with the OAuth experts.

Advertisements

<venting>

I know I’m going to sound like an old guy but I do miss programming in C. Of course, working for Sun micro and on web services, using Java is an obvious choice but, still, I really miss my C days

First off, I think Java has become way too complex. There must be APIs for every single person on the planet that got unhappy with the existing ones. Just look at all the ways one can use to handle inputs! I know lots of it has to do with ease of development and make sure nothing goes wrong at runtime etc. but, boy, does it come at a price? Too much choice has a detrimental effect on programmers IMO; If, after writing some code, you need to check whether this is the latest/greatest API to do what you intend to do then I say something’s wrong. Perhaps I do need a refreshing/crash course in Java but just looking at the number of deprecated APIs makes me think we might have gone a bit too far. It seems to me design goal 1.2.1 has been slightly forgotten in Java’s recent versions…

What I also liked in C is its simple set of instructions, the fact that you really need to pay attention to things like memory allocation. Don’t you miss malloc() and free()?? :) 

As for object-oriented programming? I like Objective-C. Take C, add a Smalltalk-based object model and you got a great do-it-all language!

To be fair, Java has so many libraries out there that, writing almost any application has become a matter of finding the right set of tools and creating some glue code around those. Of course the writing once running (almost) everywhere is neat too (although if carefully written a C program can be very portable).

As a student, I learned pascal and found it was a good language to start with (simple enough to teach you the basics of procedural programming). For object oriented, Java would be great if not for its many APIs that do get student distracted from the fundamentals. What do you reckon is the best language to learn OO programming?

All right – back to my Java programming (using the fantastic Netbeans IDE v6.5 – really, try it out!)

</venting>

The nice thing with living at the foot of the Alps and literally at the bottom of a hill is that you get to see lots of variations of the same place. The 2 photos below clearly illustrate that.

In my previous post I mentioned that default application server settings had fairly low limits to the size of HTTP headers they will support (e.g. Glassfish 2 is limited to 4KB). Well, having hit that limit in the experimentations I described previously, we looked at how one can increase such parameter in Glassfish. Here’s a recipe my good friend Marc gave me:

 Here’s how to configure a larger buffer size:

  • start glassfish
  • bring up the admin console
  • navigate to Configuration->HTTP Service->HTTP Listeners->http-listener-1
  • add a property to the table at the bottom of the page bufferSize=8192 (or whatever size you want)
  • make sure you hit the return key to save the new property once you enter the value, you can double check that the change took by navigating away from the current page and then back again
  • restart glassfish

That’s it…

The project I work on (and previously described here) requires message authentication. By that I mean the recipient of a message needs to know and verify the identity the message is about. That functionality is usually carried out by adding a security token to the message. SAML defines a very flexible format for such security token, called authentication assertion (note: SAML also defines a set of protocols to provide single sign on as well as single log out).

OAuth provides a nice, standardized, way of conveying (and obtaining) a security token in an HTTP based environment. Since our framework is a RESTful one and in an attempt to not reinvent the wheel, we thought we should leverage OAuth’s mechanism as far as message authentication goes. Namely, we tested to inject a SAML authentication assertion in HTTP’s Authorization header as defined in OAuth.

Before describing the issue, it is important to remember that carrying a security token is one thing, trusting its content (and integrity) is another. Part of the validation process for a SAML assertion is for its recipient to confirm the subject of the assertion. That is, to verify the correspondence between the principal (i.e. the subject) described in the assertion and the party with whom the recipient is conversing with. There are several methods for subject confirmation, but in many cases (at least in our project) Holder-of-Key (HoK) is the method that’s used. In the HoK case, the assertion contains digital signature information (<ds:KeyInfo>) that must match the also embedded X.509 public key certificate data.

Such assertion can get you at around 5KB and that’s where the problem lies. Most web servers out there, when left on their default settings won’t support headers of that size…

So we need to find an alternative to this approach.

One idea would be to switch to different type of tokens, possibly binary ones like Kerberos in the hope of making it smaller. However a Kerberos token can get pretty big too since nesting (of groups) is possible. Also we’d loose a lot of the flexibility that comes with SAML tokens.

So what can we do?
I’ll post a follow up soon on the solution we’ve devised but of course suggestions are more than welcome!

 

OK, not very original but I guess there must be one entry with this title…
For starters, let me say that this blog is basically the follow up of my previous blog that is still hosted here. Why moving to WordPress? No, no, I still work at SUN and although recent news have not been great, I’m fortunate to work on a pretty exciting project.
I did, however, want to try something else, change the tone and variety of my blog and since there’s so much time I can dedicate to writing blog entries I thought I’d try this (many thanks to Lauren for suggesting using WordPress and relentlessly encouraging me to blog again).