SPKM3 Issues
From Linux NFS
Line 1: | Line 1: | ||
1. should HMAC-SHA1 be added as an I-ALG? kerberos proposed to use sha1 with aes not md5. | 1. should HMAC-SHA1 be added as an I-ALG? kerberos proposed to use sha1 with aes not md5. | ||
+ | |||
Comments: ? | 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? | 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: ? | 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? | 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: ? | 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? | 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: ? | Comments: ? | ||
+ | |||
5. should the target match the target_name in REQ-TOKEN to its certificate? | 5. should the target match the target_name in REQ-TOKEN to its certificate? | ||
Comments: ? | 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? | + | |
+ | 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: ? | 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. | 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: ? | 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. | 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: ? | Comments: ? | ||
+ | |||
9. after generating an error token, should the target return CONTINUE_NEEDED or error codes from accept_sec_context()? | 9. after generating an error token, should the target return CONTINUE_NEEDED or error codes from accept_sec_context()? | ||
+ | |||
Comments: ? | Comments: ? | ||
+ | |||
10. should SPKM support SSH keys? what does it mean to support SSH keys? | 10. should SPKM support SSH keys? what does it mean to support SSH keys? | ||
+ | |||
Comments: ? | Comments: ? | ||
+ | |||
11. should SPKM have a mandatory confidentiality algorithm? is exportability still a problem? | 11. should SPKM have a mandatory confidentiality algorithm? is exportability still a problem? | ||
+ | |||
Comments: ? | Comments: ? | ||
+ | |||
12. what exactly does it mean: "md5WithRSAEncrytion is essentially equivalent to md5WithRSA"? | 12. what exactly does it mean: "md5WithRSAEncrytion is essentially equivalent to md5WithRSA"? | ||
+ | |||
Comments: ? | 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. | 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: ? | Comments: ? | ||
+ | |||
14. how PKIX1Implicit88 is different from PKIX1Explicit88? | 14. how PKIX1Implicit88 is different from PKIX1Explicit88? | ||
+ | |||
Comments: ? | Comments: ? | ||
+ | |||
15. what should the lifetime of the SPKM3 context be? | 15. what should the lifetime of the SPKM3 context be? | ||
+ | |||
Comments: ? | Comments: ? | ||
+ | |||
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) |
Revision as of 16:29, 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 SPKM-REQ is not used --