[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ANX bakeoff ISAKMP issues
> The following ISAKMP issues were encountered at the recent ANX IPSec
> Interoperability tests in Detroit.
>
> No 'HMAC Algorithm' attribute should to be sent when negotiating AH.
> This is redundent, since the same information is presented in the
> transform ID.
Agreed. The DOI talks about this attribute in conjunction with ESP but
I guess it should be more explicit.
> Should the Protocol and Port from the IPSEC-DOI ID Payload be included
> in the hashes?
Absolutely! They're part of the ID.
> There needs to be a clarification of the "Protocol" that is used to
> derive the KEYMAT.
> KEYMAT = prf(SKEYID_D, [ g(qm)^xy ] | PROTOCOL | SPI | Ni | Nr )
> Should be it IP_PROTO_ESP or ISAKMP_PROTO_ESP ?
It's the protocol and SPI from the proposal as defined in the base ISAKMP
draft figure 6.
> If I initiate a MainMode, but then the peer initiates QuickMode, what is
> the initiator cookie for QuickMode? His or mine? MainMode's initiator
> or QuickMode's initiator?
"mine"-- MainMode's initiator. The cookies together identify the ISAKMP SA,
if you flip them they'll identify something else-- or nothing. There has
been demonstrated interoperability doing this already so I figured it was
clear. I can add some explicit verbage to the resolution doc on this.
> Keep AH, allow encryption-less ESP, but it should be documented in a
> separate ESP null-cipher draft that uses the same formating as all the
> rest of the ESP cipher (DES, 3DES, RC5, CAST)` drafts.
This isn't really an ISAKMP issue.
> In RSA_SIG mode, should we send a CertReq payload when you want the peer
> to send their Certificate. (HDR, SA, CERTREQ) This might be required
> since the CERT payload is optional and the peer does know whether you
> want their certificate or not. Should we place wording in the draft
> that CertReq payloads must be supported and may be in the first MainMode
> RSA_SIG exchange.
If you need a cert then ask for one, but I don't think any ancillary payloads
(like the CERTREQ) should be required. Also, for MainMode I don't think it
should be HDR, SA, CERTREQ since the SA might also include a pre-shared key
protection suite that might end up being selected. The CERTREQ should go in
the 2nd round trip-- i.e. HDR, KE, Ni/r, CERTREQ. For AggressiveMode, yea,
it should go in the 1st message.
> Should the CA_DISTGUISHED_NAME attribute be defined in IPSEC-DOI when it
> is also being used in MainMode for Certificate Requests?
As opposed to being in the resolution doc? Hmmm, I dunno.
> Padding of individual ISAKMP payloads causes problems for payloads like
> Certificate Payloads. BCERT could not properly parse certificate blobs
> with padding added on the end. Let's get rid of individual ISAKMP
> payload padding or add another field to the certificate payload to state
> the real length of the certificate. Preferably th first option.
Yea, I never understood that requirement. Let's just do away with it.
> The KEY_LENGTH attribute is needed in MainMode negotiations for variable
> key length cipher algorithms like CAST128 and RC5.
It's already there: Attribute #14 (in Appendix A). But the *real* reason
it was added was not CAST128 or RC5, it was Blowfish (insert emoticon here).
Also, I'd like to add that the base ISAKMP draft should clear up the
SPI size confusion. Section 2.4 says that all SPIs must be 8 octets but
the proposal payload includes a SPI length field to say how long the SPI
is and notes that the SPI field itself is variable. For IPSec the SPI is
4 octets so just pass 4 and say so. I think the 2.4 verbage is a leftover
and would like to see it stricken.
Dan.
Follow-Ups:
References: