|Main Archive Page > Month Archives > ipsec archives|
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. -- email@example.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec