Re: [IPsec] Issue #26: Missing treatment of error cases

[Tero Kivinen <kivinen at iki.fi>]

Yoav Nir writes:
> > Yes, altought I think most of the implementations do not bother
> > sending INFORMATIONAL requests when IKE_AUTH response has errors. I
> > think most implementations will then simply remove the IKE SA as
> > failed without any further communications to the other end
> 
> But wouldn't this cause a state de-synchronization?

Yes, but not in normal case.

> If the responder  
> sends a revoked certificate, the initiator will have no IKE SA, but  
> the responder would have an IKE SA, which it thinks is valid. Wouldn't  
> this necessarily later lead to requests that time out?

Then the responder is already going against the RFC4306 which says
"Certificate revocation checking must be considered during the
chaining process used to select a certificate. " meaning the responder
cannot send certifiate which itself considers revoced. Only case when
this can happen is when responder thinks he has valid certificate but
initiator then checks it against certificate authority's system (for
example OCSP) and finds out it is not valid anymore. This is not
common case, thus it can lead to timeouts. 

> > In cases where the other end is unknown (i.e. ID is not configured to
> > the policy) it will return NO_PROPOSAL_CHOSEN as it does not find
> > valid policy to accept the other ends proposal when looking it based
> > on the ID.
> 
> That allows for ID enumeration. It's similar to a password entry form,  
> that says "wrong user" or "wrong password".  An attacker would be able  
> to verify whether a particular ID (say, user name) exists on a system.

If the other ends source IP-address is not configured to system (and
no wildcard entry found) then it will always return NO_PROPOSAL_CHOSEN
regardless of the ID or AUTH payloads.

Anyways active attacker can always find out the used IDs anyways. Also
from timing it is easy to see whether other end actually did only
database lookup for the ID, or whether he actually verified the RSA
signature.

If you consider ID enumeration a problem that needs to be added to the
Security Considerations section (regardless whether we return
AUTHENTICATION_FAILED or NO_PROPOSAL_CHOSEN in this case). 

> > This "MOST NOT" would make such implementations non-conforming,
> > meaning every single implementation must do full parsing of the
> > payloads first and only after that do second phase when it processes
> > the payloads.
> 
> How about if we limit this to packets that are malformed in their  
> entirety, rather than some particular payload (and packets that have  
> unrecognized critical payloads) ?

If you say MUST in any of these error cases you need to be very
specific which cases are covered, most likely giving similar pseudo
code saying you first check this, and if it fails, return this error
code, then you check this and so on...

Similar than RFC2408 Section 5 did, but even then you most likely get
implementations which do things differently because they just happen
to use some external library or other thing that does parts of the
checks in different order than what is listed in the RFC.

I have been explaining this to several customers when they have run
some external tester which required specific error code to be reported
in specific case, and we returned some other error code because we
checked things in different order.

Thats why it is bad idea to specify MUSTs (or even SHOULDs) when
taking which error to return. It is ok to say this check MUST be done
(especially if it is security related), but there is no point of
listing the order or specific error codes in all possible places.
-- 
kivinen at iki.fi