[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: XAUTH is broken

To: "Valery Smyslov" <svan@trustworks.com>
Subject: RE: XAUTH is broken
From: Tero Kivinen <kivinen@ssh.fi>
Date: Mon, 2 Aug 1999 00:56:32 +0300 (EET DST)
Cc: Stephane Beaulieu <sbeaulieu@TimeStep.com>, ipsec@lists.tislabs.com, ipsra <ietf-ipsra@vpnc.org>
In-Reply-To: <199907270635.KAA07497@relay1.trustworks.com>
Organization: SSH Communications Security Oy
References: <319A1C5F94C8D11192DE00805FBBADDFC41344@exchange><199907270635.KAA07497@relay1.trustworks.com>
Sender: owner-ipsec@lists.tislabs.com

Valery Smyslov writes:
> But the usage of Attribute payload id in XAUTH is still unclear. 
> Should it be the same for all attribute payloads within one XAUTH 
> exchange or should it be changed with every REQUEST/REPLY SET/ACK 
> pair (as ISAKMP-CFG requires)? The former seems to simplify 

I think it should remain same all the time. I could not find any
reference from the ISAKMP-CFG saying it must be changed every time.
The draft-ietf-ipsec-isakmp-mode-cfg-04.txt just says it is "An
identifier used to reference a configuration transaction within the
individual messages."

> processing a bit while the latter more strictly follows ISAKMP-CFG 
> draft (is it really needed if we define XAUTH as new exchange?).

I don't think it is good idea to define new XAUTH exchange. There is
no need for that. We can just use multiple configuration mode
exchanges using the same attribute payload id, but different message
id, until we see SET(STATUS=OK) message.

The state machine is quite simple, and it does not interfare any way
with the configuration modes used to implement the transport system
(sending/receiving those attribute payloads). I think it makes things
much easier if we just use cfg-mode as transport layer, without any
modifications to it, and use "upper level state machine" to drive the
xauth. This same "upper level state machine" is also used to decide
things like do we need to get ip-address from the server, when can we
start quick mode exchange etc. 

> > As for your question about concurrent XAUTHs.  The answer is no.   There's
> > only one way end an XAUTH for a user and that's to send an SET(STATUS(OK))
> > message.  If you were to have multiple XAUTH transactions, how could you
> > tell when it's "really" done.  There are mechanisms that allow you to send 2
> > REQUESTs within 1 XAUTH transaction.

If there is multiple xauth transactions going, they all should have
different attribute payload id. 

Only reason for that I can think of is if the server does not know
what client is capable of doing. I.e server might start multiple
xauths and see which of those the client selects, and when any one of
those is successfully finished, then the server will allow quick mode
exchange for that user. 
-- 
kivinen@iki.fi                               Work : +358-9-4354 3218
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/

Next by Date: Processing multiple phase 2 SA payloads
Next by thread: Processing multiple phase 2 SA payloads
Index(es):
- Main
- Thread