From: SourceForge.net <no...@so...> - 2008-03-28 15:42:41
|
Bugs item #1928066, was opened at 2008-03-28 08:42 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541482&aid=1928066&group_id=74601 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Authentication constants overloaded -- breaks GSSAPI support Initial Comment: Theses two constants are defined to the same value under src/racoon/oakley.h: #define OAKLEY_ATTR_AUTH_METHOD_XAUTH_PSKEY_I 65001 #define OAKLEY_ATTR_AUTH_METHOD_GSSAPI_KRB 65001 When racoon is compiled with both --enable-hybrid and --enable-gssapi GSSAPI authentication breaks since racoon decides its actually referring to the XAUTH_PSKEY authentication mode. By changing the OAKLEY_ATTR_AUTH_METHOD_XAUTH constants to differ from the OAKLEY_ATTR_AUTH_METHOD_GSSAPI constants I was able to compile with both --enable-hybrid and --enable-gssapi with working GSSAPI authentication. Log entries of the problem when authenticating with GSSAPI: 2006-02-09 15:40:44: DEBUG: begin QUICK mode. 2006-02-09 15:40:44: ERROR: Hybrid auth negotiated but peer did not announced as Xauth capable 2006-02-09 15:40:44: ERROR: Attempt to start phase 2 whereas Xauth failed 2006-02-09 15:40:44: ERROR: failed to begin ipsec sa negotication. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541482&aid=1928066&group_id=74601 |
From: SourceForge.net <no...@so...> - 2008-03-28 21:18:12
|
Bugs item #1928066, was opened at 2008-03-28 08:42 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541482&aid=1928066&group_id=74601 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Authentication constants overloaded -- breaks GSSAPI support Initial Comment: Theses two constants are defined to the same value under src/racoon/oakley.h: #define OAKLEY_ATTR_AUTH_METHOD_XAUTH_PSKEY_I 65001 #define OAKLEY_ATTR_AUTH_METHOD_GSSAPI_KRB 65001 When racoon is compiled with both --enable-hybrid and --enable-gssapi GSSAPI authentication breaks since racoon decides its actually referring to the XAUTH_PSKEY authentication mode. By changing the OAKLEY_ATTR_AUTH_METHOD_XAUTH constants to differ from the OAKLEY_ATTR_AUTH_METHOD_GSSAPI constants I was able to compile with both --enable-hybrid and --enable-gssapi with working GSSAPI authentication. Log entries of the problem when authenticating with GSSAPI: 2006-02-09 15:40:44: DEBUG: begin QUICK mode. 2006-02-09 15:40:44: ERROR: Hybrid auth negotiated but peer did not announced as Xauth capable 2006-02-09 15:40:44: ERROR: Attempt to start phase 2 whereas Xauth failed 2006-02-09 15:40:44: ERROR: failed to begin ipsec sa negotication. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2008-03-28 14:17 Message: Logged In: NO I suspect this is due to the Xauth code not actually checking to see if the Vendor ID indicates the client is attempting an Xauth authentication or if it is actually attempting GSSAPI authentication since the constant 65001 is valid for both. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541482&aid=1928066&group_id=74601 |
From: SourceForge.net <no...@so...> - 2008-03-28 21:56:52
|
Bugs item #1928066, was opened at 2008-03-28 08:42 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541482&aid=1928066&group_id=74601 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Authentication constants overloaded -- breaks GSSAPI support Initial Comment: Theses two constants are defined to the same value under src/racoon/oakley.h: #define OAKLEY_ATTR_AUTH_METHOD_XAUTH_PSKEY_I 65001 #define OAKLEY_ATTR_AUTH_METHOD_GSSAPI_KRB 65001 When racoon is compiled with both --enable-hybrid and --enable-gssapi GSSAPI authentication breaks since racoon decides its actually referring to the XAUTH_PSKEY authentication mode. By changing the OAKLEY_ATTR_AUTH_METHOD_XAUTH constants to differ from the OAKLEY_ATTR_AUTH_METHOD_GSSAPI constants I was able to compile with both --enable-hybrid and --enable-gssapi with working GSSAPI authentication. Log entries of the problem when authenticating with GSSAPI: 2006-02-09 15:40:44: DEBUG: begin QUICK mode. 2006-02-09 15:40:44: ERROR: Hybrid auth negotiated but peer did not announced as Xauth capable 2006-02-09 15:40:44: ERROR: Attempt to start phase 2 whereas Xauth failed 2006-02-09 15:40:44: ERROR: failed to begin ipsec sa negotication. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2008-03-28 14:56 Message: Logged In: NO Cross-posting this to mailing list as well: I believe I've found a bug with racoon that is trigged when compiled with the --enable-hybrid and --enable-gssapi flags. The bug itself is below (a patch to fix is available at the end of this message): if ((iph1->mode_cfg->flags & ISAKMP_CFG_VENDORID_XAUTH) == 0) { plog(LLV_ERROR, LOCATION, NULL, "Hybrid auth negotiated but peer did not " "announced as Xauth capable\n"); return -1; } Both the xauth extension [draft-ietf-ipsec-isakmp-xauth-06] and GSSAPI extension [http://tools.ietf.org/id/draft-ietf-ipsec-isakmp-gss-auth-07.txt] to ipsec use the private authentication identifier range starting at 65001. If the xauth code sees one of its authentication ids being used with a different vendor code it returns -1 and the phase2 negotiation fails. This is incorrect behavior as other authentication extensions differentiated by vendor ids share the same private authentication. The xauth code is currently aborting the phase2 negotiation before any other authentication extension can run. I believe the correct behavior should be to warn the user that something fishy might be going on and return 0 from this function. This is the same behavior that a non-private authentication code would have. Once returned the phase2 negotiation could continue with other authentication extensions (GSSAPI). I originally encountered this problem on a Debian Etch system attempting to do GSSAPI authentication with ipsec-tools 0.6.6-3.1etch1. The problem still appears to be in the latest ipsec-tools release. Below is a patch that I have tested against 0.6.6-3.1etch1 with success: --- isakmp_xauth.c 2006-06-12 14:06:01.000000000 -0400 +++ /afs/metacarta.com/user/gharris/isakmp_xauth.c 2008-03-28 17:46:47.000000000 -0400 @@ -742,10 +742,14 @@ case OAKLEY_ATTR_AUTH_METHOD_XAUTH_RSAENC_I: case OAKLEY_ATTR_AUTH_METHOD_XAUTH_RSAREV_I: if ((iph1->mode_cfg->flags & ISAKMP_CFG_VENDORID_XAUTH) == 0) { - plog(LLV_ERROR, LOCATION, NULL, + plog(LLV_WARNING, LOCATION, NULL, "Hybrid auth negotiated but peer did not " - "announced as Xauth capable\n"); - return -1; + "announced as Xauth capable -- possibly a" + "different authentication extension\n"); + /* we must return 0 to allow other extensions + * overloading the private authentication ids + * a chance to run */ + return 0; } if (xst->status != XAUTHST_OK) { ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2008-03-28 14:17 Message: Logged In: NO I suspect this is due to the Xauth code not actually checking to see if the Vendor ID indicates the client is attempting an Xauth authentication or if it is actually attempting GSSAPI authentication since the constant 65001 is valid for both. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541482&aid=1928066&group_id=74601 |
From: SourceForge.net <no...@so...> - 2009-01-16 11:04:11
|
Bugs item #1928066, was opened at 2008-03-28 17:42 Message generated for change (Comment added) made by fabled80 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541482&aid=1928066&group_id=74601 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Authentication constants overloaded -- breaks GSSAPI support Initial Comment: Theses two constants are defined to the same value under src/racoon/oakley.h: #define OAKLEY_ATTR_AUTH_METHOD_XAUTH_PSKEY_I 65001 #define OAKLEY_ATTR_AUTH_METHOD_GSSAPI_KRB 65001 When racoon is compiled with both --enable-hybrid and --enable-gssapi GSSAPI authentication breaks since racoon decides its actually referring to the XAUTH_PSKEY authentication mode. By changing the OAKLEY_ATTR_AUTH_METHOD_XAUTH constants to differ from the OAKLEY_ATTR_AUTH_METHOD_GSSAPI constants I was able to compile with both --enable-hybrid and --enable-gssapi with working GSSAPI authentication. Log entries of the problem when authenticating with GSSAPI: 2006-02-09 15:40:44: DEBUG: begin QUICK mode. 2006-02-09 15:40:44: ERROR: Hybrid auth negotiated but peer did not announced as Xauth capable 2006-02-09 15:40:44: ERROR: Attempt to start phase 2 whereas Xauth failed 2006-02-09 15:40:44: ERROR: failed to begin ipsec sa negotication. ---------------------------------------------------------------------- Comment By: Timo Teräs (fabled80) Date: 2009-01-16 13:04 Message: Closing all sourceforge.net bugs. If this issue has not been cared for please submit a new bug report to https://trac.ipsec-tools.net/ issue tracker. Thank you. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2008-03-28 23:56 Message: Logged In: NO Cross-posting this to mailing list as well: I believe I've found a bug with racoon that is trigged when compiled with the --enable-hybrid and --enable-gssapi flags. The bug itself is below (a patch to fix is available at the end of this message): if ((iph1->mode_cfg->flags & ISAKMP_CFG_VENDORID_XAUTH) == 0) { plog(LLV_ERROR, LOCATION, NULL, "Hybrid auth negotiated but peer did not " "announced as Xauth capable\n"); return -1; } Both the xauth extension [draft-ietf-ipsec-isakmp-xauth-06] and GSSAPI extension [http://tools.ietf.org/id/draft-ietf-ipsec-isakmp-gss-auth-07.txt] to ipsec use the private authentication identifier range starting at 65001. If the xauth code sees one of its authentication ids being used with a different vendor code it returns -1 and the phase2 negotiation fails. This is incorrect behavior as other authentication extensions differentiated by vendor ids share the same private authentication. The xauth code is currently aborting the phase2 negotiation before any other authentication extension can run. I believe the correct behavior should be to warn the user that something fishy might be going on and return 0 from this function. This is the same behavior that a non-private authentication code would have. Once returned the phase2 negotiation could continue with other authentication extensions (GSSAPI). I originally encountered this problem on a Debian Etch system attempting to do GSSAPI authentication with ipsec-tools 0.6.6-3.1etch1. The problem still appears to be in the latest ipsec-tools release. Below is a patch that I have tested against 0.6.6-3.1etch1 with success: --- isakmp_xauth.c 2006-06-12 14:06:01.000000000 -0400 +++ /afs/metacarta.com/user/gharris/isakmp_xauth.c 2008-03-28 17:46:47.000000000 -0400 @@ -742,10 +742,14 @@ case OAKLEY_ATTR_AUTH_METHOD_XAUTH_RSAENC_I: case OAKLEY_ATTR_AUTH_METHOD_XAUTH_RSAREV_I: if ((iph1->mode_cfg->flags & ISAKMP_CFG_VENDORID_XAUTH) == 0) { - plog(LLV_ERROR, LOCATION, NULL, + plog(LLV_WARNING, LOCATION, NULL, "Hybrid auth negotiated but peer did not " - "announced as Xauth capable\n"); - return -1; + "announced as Xauth capable -- possibly a" + "different authentication extension\n"); + /* we must return 0 to allow other extensions + * overloading the private authentication ids + * a chance to run */ + return 0; } if (xst->status != XAUTHST_OK) { ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2008-03-28 23:17 Message: Logged In: NO I suspect this is due to the Xauth code not actually checking to see if the Vendor ID indicates the client is attempting an Xauth authentication or if it is actually attempting GSSAPI authentication since the constant 65001 is valid for both. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541482&aid=1928066&group_id=74601 |