[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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.
>Should the Protocol and Port from the IPSEC-DOI ID Payload be included in the
>There needs to be a clarification of the "Protocol" that is used to derive
>KEYMAT = prf(SKEYID_D, [ g(qm)^xy ] | PROTOCOL | SPI | Ni | Nr )
>Should be it IP_PROTO_ESP or ISAKMP_PROTO_ESP ?
>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
>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.
>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.
>Should the CA_DISTGUISHED_NAME attribute be defined in IPSEC-DOI when it is
>also being used in MainMode for Certificate Requests?
>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.
>The KEY_LENGTH attribute is needed in MainMode negotiations for variable key
>length cipher algorithms like CAST128 and RC5.
>TimeStep Corporation http://www.timestep.com
>(613) 599-3610 x4808