[Openswan dev] XAUTH Code for "Domain"

[Michael H. Warfield]

On Tue, 2011-06-28 at 12:20 -0400, Michael H. Warfield wrote: 
> On Tue, 2011-06-28 at 11:48 -0400, Paul Wouters wrote: 
> > On Tue, 28 Jun 2011, Michael H. Warfield wrote:
> > 
> > > IAC...  Looking in programs/pluto/xauth.c down around line 1241 is a
> > > case statement checking the XAUTH attribute types.  That's only handling
> > > TYPE, USER_NAME, and PASSWORD - no DOMAIN.  That appears to be handling
> > > attribute responses, though (XAUTH Server?).
> > 
> > > "nm-conn1" #1: XAUTH: Unsupported attribute: XAUTH-DOMAIN
> > 
> > > So, it looks like that support is just not there.  In addition to the
> > > XAUTH code itself, this would also require some parameter support in the
> > > config files for a "domain" parameter.
> > >
> > > Thoughts?  Is this anything already on anyone's todo list?
> 
> > Not that I know. Patches accepted :)

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.

It looks like I need to add additional ENUMS to that RC_ set and add new
branches throughout this code back through pluto and whack.

Either way, it looks like I'm going to need to touch a few more source
files than I had hoped to, originally.  Before I do that, I would like
to hear some opinions if adding to that ENUM is the correct path to take
or am I missing another option (no pun intended) here?

Regards,
Mike

> I know da drill...  :-P  Just didn't want to dig too deep and start
> tripping over other people and stepping on toes.
> 
> I've already got my nose stuffed into xauth.c and the configuration
> routines.  Looks like there may be a couple of things that need to be
> handled in there based on my reading of some old ietf drafts.
> 
> I can add a {left|right}xauthdomain parameter and make that mirror the
> xauthusername handling all the way into xauth.c.  Been chatting with
> Avesh about it separately since this will also have to coord with
> NetworkManager-openswan to handle the Domain parameter.
> 
> There's also an XAUTH_PASSCODE and an XAUTH_NEXTPIN, in the spec I have,
> intended for tokens that has me a little concerned since one of the
> connections I'm looking at involves an RSA SecureID token (I guess that
> would parallel the password code).  Everywhere in vpnc where I see
> PASSWORD, I'm seeing identical PASSCODE handling (generally just another
> option on the case statements).  If it's there in vpnc then there's
> likely some Cisco out there somewhere doing it.  :-/=/
> 
> Then there's some sort of XAUTH_CHALLENGE which should probably be
> handled similar to XAUTH_MESSAGE and XAUTH_MESSAGE isn't really being
> handled right to begin with since that's also for messages like "Enter
> User Name and Password" kinds of stuff as well and we're logging it as a
> "Bad" message.  Is there a way to display a message like that through
> whack without prompting for input?  I guess there must be.  I'll track
> that down too.  Looks like fun.  As long as I'm in there already.
> 
> For now, I'm ONLY going to look at the client side, even though Openswan
> can be and XAUTH server.  If we've gotten this far down the road without
> them in the client side, I doubt we'll need them in the server side
> anytime soon.
> 
> > Paul
> 
> Regards,
> Mike
> _______________________________________________
> 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/20110701/47ceb7cf/attachment.bin