From Linux NFS

Names in SPKM3

One of the main issues SPKM3 draft needs to address is naming. X500 distinguished name has no predefined canonical form. rfc2253 defines a string representation of an X500 distinguished name but it is not in a canonical form. it imposes no ordering of multi-valued RDNs. rfc2253 does not take care of white spaces. in the SPKM3 draft, we take care of such issues. however, it is still not possible to have printable canonical names. some implementation may lack an OID-to-string translation for an attribute present in an X500 distinguished name. in such case, rfc2253 proposes to use the hex value of the OID (for more details see rfc2253). however, der-encoded rfc2253 gets us closer to a canonical binary representation of an X500 distinguished name.

 -- issue: case sensitivity. each RDN's AttributeValueAssertion (AVA) can define its own matching rules. for instance,
 it can state that values of this attribute are case insensitive. can we just declare that values are always case
 insensitive.

rfc2743 defines three name classes: an internal name (special case being a mechanism name), contiguous ("flat") name, and an exported name (canonicalized name). for spkm3, contiguous name is an rfc2253 string representation of the DN + order & white spaces rules. for spkm3, an exported name is a der-encoded contigous name.

Unresolved questions

1. Should HMAC-SHA1 be added as an I-ALG? kerberos proposed to use sha1 with aes not md5.

Comments: ?

2. If the targer receives a REQ-TOKEN such that integrity alg=null-mac but there the src_name is not "anonymous". is this an invalid token?

Comments: ?

3. If the target receives a REQ-TOKEN such that integrity alg=md5WithRSA but there is no src_name. is this an invalid token?

Comments: ?

4. If the initiator receives a REP-TI-TOKEN and the target_name there doesn't match the target name in REQ-TOKEN, however, the target name in REQ-TOKEN matches the target's certificate. is this an invalid token?

Comments: ?

5. Should the target match the target_name in REQ-TOKEN to its certificate? Comments: ?

6. If the target receives a REQ-TOKEN such that integrity alg=md5WithRSA but the mutual_state within Options within ContextData is not set (or set to anonymous). is this an invalid token?

Comments: ?

7. In the spec, we state target-certif-data-required must be set to 1. what if it is not? is in an invalid token? or should the target still just send the REP-TI back.

Comments: ?

8. What should happen if an initiator or the target fails to process an error token? the spec does say that an invalid error token should still require a new SPKM-REQ token to be generated and sent.

Comments: ?

9. After generating an error token, should the target return CONTINUE_NEEDED or error codes from accept_sec_context()?

Comments: ?

10. Should SPKM support SSH keys? what does it mean to support SSH keys?

Comments: ?

11. Should SPKM have a mandatory confidentiality algorithm? is exportability still a problem?

Comments: ?

12. What exactly does it mean: "md5WithRSAEncrytion is essentially equivalent to md5WithRSA"?

Comments: ?

13. What happens when the anonymous initiator has trouble with rep-ti-token and is unable to derive a context key, therefore it can not use any other I-ALG but NULL-MAC.

Comments: ?

14. How PKIX1Implicit88 is different from PKIX1Explicit88?

Comments: ?

15. What should the lifetime of the SPKM3 context be?

Comments: ?

16. SPKM3 tokens have a number SPKM1/2 artifacts left behind. Currently they are kept for backward compatability. Should they be removed? Examples:

• Leaving old ERROR token (we should only be using the new SPKM-GSS-ERROR token)
• auth-data (AuthorizationData) in SPKM-REQ should either be removed or we need to add a checksum that ties the authorization data to the rest of the token's content.
• Timestamp field in tokens is not used by SPKM3
• key-src-bind in Req-contents is not used
• certif-data in SPKM-REP-TI should be MANDATORY (it was not but we made it so. is it ok?)
• key-estb-id in Rep-ti-contents

Comments: ?