[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: