[security-services] AI-42: SAML error codes...

[Carlisle Adams <carlisle.adams@entrust.com>]

Title: Question regarding SAML error codes...

Hi all,

 

With respect to AI-42 ("Carlisle to investigate SAML errors specification and impact on interoperability"), I've taken a further look at the codes suggested below.

 

I agree with Rob Philpott (I believe it was Rob) that some types of error codes can lead to security vulnerabilities, in that they give a potential attacker too much information and allow the attacker to repeatedly modify his/her request until some success is achieved.  Not all error codes fall into this category, but those that don't seem less useful to the legitimate requester who would like to do automated error recovery or trouble-shooting.

 

I still see value in having detailed error codes defined and used for testing/interoperability purposes and then turned off for production environments.  However, the trouble is that once we standardize such codes, some subset of products will probably not abide by this distinction and will thus open themselves up to security vulnerabilities.  Additional text in the Security and Privacy Considerations section won't prevent this, either.

 

So, I'm willing to agree with Rob that the best course of action is to stick with the very generic and high-level error codes we have already defined in SAML 1.0.  Individual implementers can certainly define and use their own private codes for other purposes or for additional detail if they wish.

 

Unless others in the TC have further comments or discussion points on this topic, I think we can consider this action item CLOSED.

 

Carlisle.

 

 

-----Original Message-----
From: Carlisle Adams [mailto:carlisle.adams@entrust.com]
Sent: Monday, February 03, 2003 5:31 PM
To: 'rphilpott@rsasecurity.com'; 'pmishra@netegrity.com'
Cc: 'security-services@lists.oasis-open.org'
Subject: [security-services] Question regarding SAML error codes...

Hi,

I recently received a question from a SAML developer regarding error codes.  Specifically, the developer was asking for

"...more detailed error information. Saml 1.0 leaves most of it to the vendors, which means automated error recovery (and possibly troubleshooting) is going to be difficult in multi-vendor environments."

When I asked for examples of what would be helpful, I got the following response:

I think there could be a code for each item in the message that might fail. Currently, the only specific error codes have to do with version mismatches and one about too many elements to be returned.

• digital signature validation failed (could get more specific wrt unknown signer DN, cryptographic problems, etc)
• missing digital signature
• bad artifact
• unknown sourceID
• unknown/expired assertionHandle (perhaps this isn't an error... for some reason, you're supposed to return "success" even if you can't/won't generate an assertion. I think there are different subcases here, and some are errors)
• request issueInstant is in the future
• request issueInstant is too far in the past (these two indicate a clock sync problem)
  

Would it be possible to discuss this briefly on tomorrow's call and see if there's any desire to include something along these lines in the 1.1 time frame?

Carlisle.