[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
Should the Protocol and Port from the IPSEC-DOI ID Payload be included
in the hashes?
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 ?
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?
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
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