RE: [Ipsec] Proposed Last Call based revisions to IKEv2

["William Dixon" <ietf-wd@v6security.com>]

Wow, I forgot to re-check that. Sorry. The hashes are a significant
improvement. Any thoughts on whether we should pursue the IKEv2 attack draft
I suggested ? I see it as a full treatment of security considerations.

> -----Original Message-----
> From: ipsec-admin@ietf.org [mailto:ipsec-admin@ietf.org] On 
> Behalf Of Tero Kivinen
> Sent: Monday, May 24, 2004 4:59 AM
> To: William Dixon
> Cc: 'Charlie Kaufman'; ipsec@ietf.org
> Subject: RE: [Ipsec] Proposed Last Call based revisions to IKEv2
> 
> William Dixon writes:
> > To the text quoted above, the optional CERTREQ from the responder 
> > reveals the trust anchors that the unauthenticated responder would 
> > presumably use to authenticate the initiator. Certain usages of the 
> > CERTREQ payload (by default for example) in products may 
> inadvertently 
> > increase the risk to the customer. The risk is when the CERTREQ 
> > contains a DN of a CA name that identifies the 
> organizational owner of 
> > the gateway, and certainly which trust infrastructure must be 
> > compromised. This could provide important information to 
> the attacker 
> > if the CA name were the lowest level of issuing authority 
> for which a 
> > certificate was accepted (such as "Defense Nuclear Analysis Branch 
> > Issuing CA"), or perhaps generally useful but less specific 
> > information if the CA DN name were the root CA name (such 
> as "Defense 
> > Dept Root CA"). The use of PKI technology and certain 
> privately owned 
> > PKIs for
> > IKEv2 may not in fact be something that is intended to be known or 
> > advertised publicly. Thus it may be necessary to rely solely upon 
> > initiator configuration or user selection to know which 
> certificate to offer.
> 
> NOte, that in IKEv2 the DN of the CA is NOT sent. The 
> Certificate request payload contains SHA-1 hashes of the 
> public keys of trusted CAs. So when the attacker see that the 
> initiator trust CA "94ea1e00fb5e85fea5e645aab20fb408dce3c4b1" 
> (in binary), it is little hard to know which CA it actually 
> trusts unless you already know the CA public key. So without 
> seeing the actual certificate you cannot know which CA it 
> trust. You can however still track that this client uses the 
> same CA than that other client....
> 
> 
> If we would want to hide that information too, we would be 
> required to add IKE-SPIs to the hash, i.e defiene that the 
> SHA-1 hashes CERTREQ are HMAC keyed hash using the IKE-SPI of 
> the hash of the public key, or similar (i.e. CERTREQ_PAYLOAD 
> = HMAC(IKE_SA initoator SPI, SAH-1 hash of the public key of CA). 
> --
> kivinen@safenet-inc.com
> 
> _______________________________________________
> Ipsec mailing list
> Ipsec@ietf.org
> https://www1.ietf.org/mailman/listinfo/ipsec
> 
> 


_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec