[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: XAUTH is broken
Valery Smyslov wrote:
<snip>
> 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?).
<snip>
The Attribute payload id should be identical for all messages in the XAUTH
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?
I don't understand why you would need multiple XAUTH exchanges for 1 User.
Is this a requirement for anyone? If so, why?
If this is a requirement, then when would the Remote Client be allowed to
initiate Quick Modes? after the first successful XAUTH, or only once
they're all complete?
I would really like to limit the number of XAUTH transactions to 1. You can
still do two different authentication schemes in 1 transaction.
Remote Edge
------- -----
<-- REQUEST(RADIUS)
REPLY (RADIUS) -->
<-- REQUEST(OTP)
REPLY(OTP) -->
<-- SET(OK)
ACK -->
QUICK MODE -->
It make the state machine simpler. As soon as you receive STATUS=OK, start
doing your QMs.