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

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:]
Sent: Monday, February 03, 2003 
  5:31 PM
To: ''; 
  ''
Cc: 
  ''
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.