SPKM3 Issues
From Linux NFS
| Line 61: | Line 61: | ||
16. SPKM3 tokens have a number SPKM1/2 artifacts left behind. currently they are kept for backward compatability. should they be removed. Examples: | 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) | -- 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. | + | -- 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 | -- timestamp field in tokens is not used by SPKM3 | ||
| - | -- key-src-bind in | + | -- 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 | ||
Revision as of 16:33, 10 May 2006
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
