[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: XAUTH is broken
On 26 Jul 99 at 11:22, Stephane Beaulieu wrote:
Hi, Stephane
> Valery,
>
> You raise a good point regarding multiple attribute payloads in the same
> Isakmp-Cfg message. I agree that this should be disallowed for XAUTH. This
> type of extensibility would probably hurt interoperability and provide no
> significant gain.
>
> Even though the Message ID / XAUTH id pair would be the same for
> transaction, I would recommend that you still keep state on the XAUTH id and
> not solely rely on Message ID. These two identifiers serve different
> purposes.
I agree. I asked this question because Tim's algorithm seems to
ignore Attribute payload id.
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
processing a bit while the latter more strictly follows ISAKMP-CFG
draft (is it really needed if we define XAUTH as new exchange?).
> 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.
You may initiate several XAUTH exchanges (with different M-ID, of
course) simultaneously. In this case each transaction will be
identified by M-ID and will be ended when SET(STATUS) will appear
in corresponding XAUTH exchange.
So, it seems that the reason you mentioned is not a real problem
here. Have I missed something?
> Thanks for your input,
> Stephane.
Regards,
Valery.
References: