[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: XAUTH is broken
>
> -----Original Message-----
> From: Valery Smyslov [mailto:svan@trustworks.com]
> Sent: July 27, 1999 6:35 AM
> To: Stephane Beaulieu
> Cc: ipsec@lists.tislabs.com; ipsra
> Subject: 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.
My "algorithm" was a quick-and-dirty illustration of the differences
required between the two. It is not and should not be treated as gospel.
What I illustrated was potentially the minimum you might need to do in order
to show why I personally preferred the new exchange number route.
> 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?).
If we use a new exchange type, then that can be defined independently of
configuration exchange, while keeping the format of the attribute payload. I
think your first suggestion (keep it across the entire exchange) is the
correct one.
> > 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?
Stephane's point was that you need a way to indicate to a higher level state
machine that the phase 1 SA is fully authenticated and that it can be used
for other things, such as quick modes. If you have multiple independent
XAUTH exchanges, what does it mean with respect to fully authenticating the
phase 1?
Unless there's a really good reason to allow this, for the sake of
interoperability, I would suggest we don't allow concurrent XAUTHS. (I
suppose one could conceive of using dual bi-directional XAUTH, but I really
don't think we want to go there right now.)
Tim