[Openswan dev] XAUTH Code for "Domain"

Tue Jul 5 14:28:02 EDT 2011

Paul, et al...

I'm still up to my eyeballs in this XAUTH code (I sent you some
preliminary code in a private E-Mail) and debugging where the Cisco ASA
seems to stop talking and we start timing out.  Turns out that was not
the case and the ASA is really telling us to bugger off and we're
ignoring it.  I've got another engineer with and ASA and we're debugging
it from both ends.  We found out that the Cisco is not accepting any of
our phase2 algorithms but Openswan is ignoring the response:

| ***parse ISAKMP Hash Payload:
|    next payload type: ISAKMP_NEXT_N
|    length: 24
| got payload 0x800(ISAKMP_NEXT_N) needed: 0x0 opt: 0x0
| ***parse ISAKMP Notification Payload:
|    next payload type: ISAKMP_NEXT_NONE
|    length: 32
|    DOI: ISAKMP_DOI_IPSEC
|    protocol ID: 3
|    SPI size: 16
|    Notify Message Type: NO_PROPOSAL_CHOSEN
"Cisco" #1: ignoring informational payload, type NO_PROPOSAL_CHOSEN msgid=00000000
| info:  be f5 c3 66  3c a2 6e 29  32 50 c9 d3  40 5e 4b 45
| info:  5f 2e 86 6f
| processing informational NO_PROPOSAL_CHOSEN (14)
"Cisco" #1: received and ignored informational message
| complete state transition with STF_IGNORE
| * processed 0 messages from cryptographic helpers
| next event EVENT_RETRANSMIT in 10 seconds for #2
| next event EVENT_RETRANSMIT in 10 seconds for #2
|

Really???  Ignore it?  Shouldn't this be a big red letter horns a
blaring serious log warning and bitch back through whack and die error?
That's a major failure there.  If that's where this problem is, the
XAUTH Domain patches are looking better and better.

I know, I know...  "Patches welcome."

Regards,
Mike

On Sat, 2011-07-02 at 14:54 -0400, Paul Wouters wrote: 
> On Fri, 1 Jul 2011, Michael H. Warfield wrote:
> 
> > Oooo...  What am I getting myself into this time?  I need some advise
> > and I'm not sure who is most familiar with some of that XAUTH code and
> > the whack prompting code.
> >
> > Ok...  The attribute handling code isn't that difficult and I think I
> > even figured out adding a {left|right}xauthdomain option and getting it
> > added to that big pack of strings between pluto and whack.  NOW I see
> > the mess with prompting for a Domain (or a Pin or a couple of other
> > things there in XAUTH).  What I found was whack_prompt only has two
> > cases switched on the echo parameter which prompts for either
> > "username" (echo = 0) or "password" (echo = 1).  It then calls whack_log
> > with either RC_XAUTHPROMPT for the username or RC_ENTERSECRET for the
> > password.  That propagates back into the message handling loop in whack
> > which then calls whack_get_value for the user name or whack_get_secret
> > for the password and each of those has their own prompts for "username"
> > and "password."  Sigh...
> >
> > First temptation would be to add a prompt string into that whole mess
> > and keep the level of added code to a minimum.  Just one routine for
> > prompt with response echo and one for prompt with no response echo.
> > OTOH, that message handling loop is also switch on returning config
> > values, so that's not going to work.
> 
> I would just limit it to keywords. The reason user and password are handled
> this way (as well as being able to be set through config files!) is that
> for OTP/token logins, either username or password can be different each login,
> and requires prompting. But I doubt the DOMAIN changes per instance of the
> xauth connection?
> 
> Paul
> _______________________________________________
> Dev mailing list
> Dev at openswan.org
> http://lists.openswan.org/mailman/listinfo/dev
> 

-- 
Michael H. Warfield (AI4NB) | (770) 985-6132 |  mhw at WittsEnd.com
   /\/\|=mhw=|\/\/          | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9          | An optimist believes we live in the best of all
 PGP Key: 0x674627FF        | possible worlds.  A pessimist is sure of it!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 482 bytes
Desc: This is a digitally signed message part
Url : http://lists.openswan.org/pipermail/dev/attachments/20110705/5d27aeb4/attachment.bin 