Re: Xauth Transaction Identifier

["Stephane Beaulieu" <stephane@xxxxxxxxx>]

Hi,

Comments inline.

>
> Thank you in advance to answer my following questions about
>  your xauth draft (Oct. 2000).
>
> 1. In Section 6, it says:
>     "All ISAKMP-Config messages in an extended authentication transaction
>      MUST contain the same ISAKMP-Config transaction identifier."
>
> Does it mean that a single "identifier" value shall be used in the whole
> xauth
> transaction ?

Yes.

>
> Then if the whole xauth exchange looks like:
> Request -->
> <--  Reply
> Request -->
> <--  Reply
> Set -->
> <--  Ack
>
> Only one id value will be used  no matter how many pairs of messages
> (Request/Reply, Set/Ack) ?

Correct

>
> 2. What is the starting value for this "identifier" ?
> Is it always incremented by 1 ?
> What will be the cases to use different identifier values ?

The identifier is inherrited  by the mode-cfg draft.  I believe it can
indeed be set to any number, and does not need to be sequential.

The purpose of the identifier is to be able to distinguish several mode-cfg
exchanges that may be occuring at the same time and/or to link several
mode-cfg exchanges together (such as XAUTH does).  Currently, I can't think
of any situations that are documented by any vendors who support the
mode-cfg draft that uses more than 1 mode-cfg exchange at a time.  Though,
it is conceivable, that someone would eventually build something on top of
mode-cfg which might do this.

>
> 3. Should we change the identifier value for the "authentication failure
> retry" ?

No.  The identifier should stay the same until the SET/ACK is complete.
Once the SET/ACK is complete that identifier should not be used anymore.

> or even the re-authentication phase (per RADIUS, as described in section
6)
> ?

Yes.  In this case we use a new identifier.  This is a whole new XAUTH
exchange (even though it is with the same peer).

>
> In addition, have you thought about how to support "password change",
which
> can be initiated by the end host or even the edge device ?

I would suggest the following for something initiated by the edge device.

Client <--> GW
<-- REQ (Username = '', pwd = '')
REPLY (Username = 'joe', pwd = 'mypwd') -->
<-- REQ (pwd = '', msg = 'Your password has expired, please enter a new
password')
REPLY (pwd = 'mynewpwd') -->
<-- SET (OK)
ACK() -->

As for the Client side initiated change of password.  I would presume that
in systems that allow this, it could be done by the Client at any time after
the tunnel comes up.  For example, I'm actually tunneling into my VPN at
Cisco using XAUTH with NT domain authentication.  Using this configuration,
I've just successfully changed my NT domain password on the corporate net.

Please let me know if you can think of problems with other types of
authentication systems in which this would not be possible.

Regards,
Stephane.

>
> Thanks again for your advise.
>
> Leemay Yen
> RapidStream, Inc.
>
>