[COMMENTS from Stephen Kent] - There are several references to non-repudiation, which are inappropriate. The use of certs and signatures as part of secure session establishment are not consistent with the generally accepted notions of NR. These mentions of NR should be deleted. [AGLO] all references to non-repudiation are deleted. - the list of features of SPKM on page 6 reads like an advertisement, and it is an inaccurate one. Most of these features are provided in TLS and IKE, for example. also, the mention of PEM support seems way out of date. [AGLO] the list of feasures is deleted. - there are two optional integrity algorithms that seem rather odd, compared to the set of such algorithms used in other, modern IETF security protocols: sum64-DES-CBC and MD5-DES-CBC [AGLO] mentioned protocols are removed - although no encryption algorithms are mandatory here (which raises interoperability questions), one of the three RECOMMENDED algorithms is cast5CBC, which also stands out as inconsistent with modern IETF algorithm practices. There is an attempt to justify the choice of this algorihm in the security considerations section, but the text there sounds like a snapshot from the early stages of the AES competition. triple-DES is also RECOMMENDED, which seems off at this time, and there is a missing reference for it (page 11). [AGLO] cast5CBC protocol is removed - Diffie-Hellman is mandated as the key establishment algorithm, but there is no reference to what DH groups MUST be supported, which is a serious omission. [AGLO] specified the same DH groups as PKINIT - the document contains two pages of "issues" (mostly unresolved questions) which seems odd if this document is ready to be approved as an RFC. Some of these issues seem to raise serious interoperability questions. [AGLO] the reviewed document should not have contained that section - there are several spelling and grammatical errors that I noticed in a quick review of the document. I did not read the detailed descriptions of the GSS-API tokens, etc. [Comments from Eric Rescorla] GENERAL COMMENTS 1. Algorithms Many of the algorithms described in this document should be replaced with more modern algorithms. For message integrity, this document specifies: HMAC-MD5 MD5/RSA SHA1/RSA DSA/SHA1 DES-MAC MD5-DES-CBC SUM64-DES-CBC The only ones of these algorithms that are appropriate for new standards are SHA1/RSA and DSA/SHA-1. Wang et al.'s results clearly imply that MD5 should be deprecated in all signature contexts and Kim et al's results [0] suggest that HMAC-MD5 at least shouldn't be put into new systems. HMAC-SHA1 is the appropriate replacement. [AGLO] modified list of i-algs contains: hmac-sha1, rsa/sha1, dsa/sha1 For confidentiality, this document specifies: AES256-CBC AES128-CBC DES-EDE3-CBC cast5CBC These are probably all fine, but there's really no longer any reason to include CAST. It also appears that somehow DES-CBC is allowed. That's really not OK. [AGLO] removed cast5CBC. all references to des-cbc are removed The OWF specified here is simply SHA-1 with the inputs concatenated. Modern KDF designs almost always have the key being a separate input value. E.g., HMAC-SHA1(key, seed....). I suggest copying the TLS PRF, the IPsec KDF, or the NIST 800-56A KDF. [AGLO] i have no objection to changing KDF. i don't know what to change it to. 2. Incomplete specification In a number of cases, the only documentation for fields is cursory comments in the ASN.1. Every field should be explained in the main body of the text. [AGLO] still need to address that. 3. MAC/signature overloading In this document, symmetric MAC algorithms and asymmetric signature algorithms are used semi-interchangeably. That's a dangerous practice which tends to lead to confusion and brittle designs. AFAICT, the signature algorithm is used to authenticate the peers and the MAC algorithm is used to authenticate data packets. Is there really any need to *sign* data packets? If there is, it should be provided with a separate facility, esp. since the current design provides no way for one side to ask for a signature on specific packets and indeed discourages negotiating it (see S 2.3.1). [AGLO] must be the english thing, caz i don't understand what's the problem here. hmac-sha1 is used for per-message packets and digital signature algorithms are used during context establishment. i don't see how it is unclear. 4. Multiple Negotiated algorithms This mechanism seems to result in negotiating the intersection of the acceptable algorithm sets. Why not just choose one algorithm and stick with it like IPsec and TLS do? This seems like it has obvious downgrade problems. [AGLO] the intersection comes from GSS API's QOP. whether or not QOP is needed is a separate issue. DETAILED COMMENTS S 2.1. A ladder diagram of the protocol flows would really help here. [AGLO] i don't see the need for that. S 2.3.2. A GSS mechanism need not support confidentiality. Making a confidentiality algorithm mandatory may preclude exportability of the mechanism implementation; this document therefore specifies certain Exportability hasn't been a major concern for quite some time. [AGLO] i removed the wording from the section. made aes algs mandatory and triple des recommended S 2.3.3. I don't understand how you upgrade to stronger groups, since the initiator sends its DH share before it talks to the server. How would you upgrade to ECC, for instance? [AGLO] the server can send an error code back saying key too weak. the client can choose to say switch from 1024bit DH to 2046bit DH. S 2.4.1.1. Conf-Algs ::= CHOICE { algs [0] SEQUENCE OF AlgorithmIdentifier, null [1] NULL, -- used when conf. is not available over context ... } Why not just allow an empty sequence instead of NULL? [AGLO] i don't know. If the SPKM-3 implementation supports an algorithm weaker than cast5CBC, cast5CBC MUST be listed before the weaker algorithm to encourage the target to negotiate the stronger algorithm. You shouldn't be specifying any algorithms weaker than cast5CBC. [AGLO] i removed this wording for both i-alg and c-alg. S 2.4.1.2. REP-TI-TOKEN ::= SEQUENCE { rep-ti-contents Rep-ti-contents, algId AlgorithmIdentifier, -- should be one of the digital signature algorithms rep-ti-integ Integrity, -- "token" is Rep-ti-contents ... } Is there some way for the peer to express which digital signature algorithms he wants? I don't see it. [AGLO] i don't understand the comment. the selection of the algorithm is expressed by an algorithm oid within the algId field. key-estb-id AlgorithmIdentifier OPTIONAL, -- used if target is changing key estb. algorithm (MUST be -- a member of initiators key-estb-set) I don't understand how this could happen. [AGLO] this is left from the SPKM2 where RSA-based key agreement protocol was one of the options. If the client started with a DH algorithm but sent an RSA amont the K-ALGs, then the server can switch. spkm3 mandates DH as it's K-ALG. i don't know if the flexibility of allowing other protocols in the future is needed. S 2.4.2.2. md5WithRsaEncryption is currently stipulated for the signing of context establishment tokens. Discrepancies involving modulus bitlength can be resolved through judicious use of the SPKM-GSS-ERROR token. The context initiator signs REQ-TOKEN using the strongest RSA it supports (e.g., 1024 bits). If the target is unable to verify signatures of this length, it sends SPKM-GSS- ERROR signed with the strongest RSA that it supports (e.g. 512). Furthermore, the target can include an appropriate minor_status value (GSS_SPKM_S_SG_WEAK_KEY). How does this work if the target has a key too big for the initiator and you're in anonymous mode? [AGLO] it doesn't work. S 2.4.3.1. SPKM-MIC ::= SEQUENCE { mic-header Mic-Header, int-cksum BIT STRING, -- Checksum over header and data, calculated according to -- algorithm specified in int-alg field. ... } The word "checksum" really isn't appropriate here. As noted previously, I think it's a mistake to treat MACs and signatures as the same thing, but if you must, the right term here is "Message Integrity Check" (MIC). [AGLO] replaced "Checksum" with "MIC" Mic-Header ::= SEQUENCE { tok-id INTEGER (257), -- shall contain 0101 (hex) context-id Random-Integer, int-alg [0] AlgorithmIdentifier OPTIONAL, -- Integrity algorithm indicator (MUST be one of the agreed -- integrity algorithms for this context). -- field not present = default id. snd-seq [1] SeqNum OPTIONAL, -- sequence number field. ... } Allowing switch-hitting of integrity algorithms seems problematic, since it basically forces one side to receive packets with the lowest jointly acceptable algorithm. Better to let the negotiation pick the single best one. [AGLO] again, qop? S 2.8. I don't understand the bit about the algorithm numbers being specified by the mechanism specification. Is that this document? This may be obvious to people steeped in GSS, but a little more explanation might help. [AGLO] left over from rfc2025. kerberos no longer uses qop. The weak/medium/strong values here are quite out of date. 40 bits is laughably weak. We should be deprecating these algorithms entirely. [AGLO] i'm not sure what weak/medium/strong values should be triple des i believe is 56 bits. then we have 128bit aes and 256 aes. then 56 or less is weak; >=56 && < 128 is medium and >=128 is strong? For the Confidentiality MA field: 0001 (1) = DES-CBC 0010 (2) = cast5CBC 0011 (3) = aes256-CBC I don't understand what happened to e.g., AES-128.... [AGLO] fixed 1,2,3 to be aes256, aes128, des-3ede-cbc S 3. Slightly more introductory text here might help. E.g., LIPKEY provides a mechanism for having target authentication via certificates and client authentication via passwords. LIPKEY is a wrapper around SPKM-3. [AGLO] added above description