[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: XAUTH is broken
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.
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.
Thanks for your input,
Stephane.
Valery Smyslov wrote:
> So, you don't pay any attention to attribute payload Identifier field
> in your processing with the same M-ID, do you? If so, then
> next problem arises:
> currently XAUTH draft doesn't prohibit multiple attribute
> payloads in one
> message (and ISAKMP-CFG explicitly allows it). If you ignore
> Identifier, you
> cannot link REQUEST with REPLY and SET with ACK unless the
> only attribute
> payload is present in every message. This restriction (only
> one attribute payload
> in every message) seems to make sense for XAUTH, so I'd
> prefer it to be mentioned
> explicitly in the draft. Even in this case we have a problem:
> what to do if Identifiers in
> consequent messages don't match - ignore, abort, consider as
> another XAUTH
> exchange? Is it ever possible to have multiple concurrent
> XAUTH exchanges?
>
> Regards,
> Valery.
>
>
> ----- Original Message -----
> From: Tim Jenkins <tjenkins@TimeStep.com>
> To: Valery Smyslov <svan@trustworks.com>;
> <ipsec@lists.tislabs.com>; Joern Sierwald
> <joern.sierwald@datafellows.com>
> Sent: Friday, July 23, 1999 5:04 PM
> Subject: RE: XAUTH is broken
>
>
> (Damn mailer dropped my response...)
>
> This is in response to questions about my objection to using multiple
> different configuration exchange exchanges for extended
> authentications that
> require more than two packets.
>
> When extended authentication is required, an overall state
> machine that
> controls the phase 1 SA has to know what the result of the extended
> authentication session is. It would be advantageous to
> minimize how much
> that state machine needs to know about the exchange.
>
> If it is done over a configuration exchange using the
> attribute payload
> identifier (or some other value common to the whole
> exchange), the state
> machine has to do the following:
>
> 1) know that extended authentication is required
> 2) check that the first packet sent is the correct exchange type
> (configuration exchange)
> 3) check that the attributes in the exchange are valid (right
> now there are
> 9 defined; it needs to know about all of them in order to
> know that this an
> XAUTH exchange)
> 4) save the message ID from the exchange
> 5) save the identifier out of the attribute payload
>
> Then, for the next packet that goes through:
>
> 1) check the packet is the correct exchange type
> (configuration exchange)
> 2) check that the message ID matches the previous exchange
> 3) look for the XAUTH_STATUS attribute
>
> If the XAUTH_STATUS attribute is found, the state machine can
> take action
> accordingly.
>
> If it's not found, the state machine has to do the next set
> of actions until
> it is found:
>
> 1) check that the next packet sent is the correct exchange type
> (configuration exchange)
> 2) check that the identifier out of the attribute payload
> matches the saved
> one
> 3) check that the attributes in the exchange are valid (right
> now there are
> 9 defined; it needs to know about all of them)
> 4) save the message ID from the exchange
> 5) check that the next packet is the correct exchange type
> (configuration
> exchange)
> 6) check that the message ID matches the previous exchange
> 7) look for the XAUTH_STATUS attribute
>
>
> Compare that work to the case where the extended
> authentication is done in
> its own open-ended exchange type:
>
> 1) know that extended authentication is required
> 2) check that the first packet sent is the correct exchange
> type (XAUTH
> exchange)
> 3) save the message ID from the exchange
>
> Then, for the remainder of the packets that go through:
>
> 1) check the packet is the correct exchange type (XAUTH exchange)
> 2) check that the message ID matches the previous exchange
> 3) look for the XAUTH_STATUS attribute (if an even numbered
> message of the
> exchange)
>
> If the XAUTH_STATUS attribute is found, the state machine take action
> accordingly.
>
> If it's not found, the state machine has to the next pair of
> actions until
> it is found:
>
> It's simpler, requires less knowledge of the exchange and
> attribute by the
> state machine.
>
> Both can be done; it seems that the separate exchange type is
> architecturally purer.
>
> Tim
>
>
> > -----Original Message-----
> > From: Tim Jenkins [mailto:tjenkins@TimeStep.com]
> > Sent: July 23, 1999 8:36 AM
> > To: Valery Smyslov; ipsec@lists.tislabs.com; Joern Sierwald
> > Subject: RE: XAUTH is broken
> >
> >
> >
> >
> > -----Original Message-----
> > From: Valery Smyslov [mailto:svan@trustworks.com]
> > Sent: July 23, 1999 9:57 AM
> > To: ipsec@lists.tislabs.com; Joern Sierwald
> > Subject: RE: XAUTH is broken
> >
> >
> >
> > On 23 Jul 99 at 10:40, Joern Sierwald wrote:
> >
> > > At 15:53 22.7.1999 -0400, you wrote:
> > >
> > > >This is a rather unfair and unreasonable accusation.
> > > Yes it is. It was meant to be a bit teasing, but it looks
> just mean
> > > if it read it today. Sorry.
> > >
> > > >If it turns
> > > >out that the best solution is to use a new exchange
> type, we would
> > > >still have to change our code, and it also one of the suggestions
> > > >that I already said I prefer.
> > > >
> > > OK, let's go this way. I would like to suggest that we
> define _two_
> > > new exchanges, one for 4 packets and one for 6 packets.
> >
> > Number of packets depends on type of authentication. Who can
> > guarantee that tomorrow another type of authentication will require,
> > say, 8 packets? Shall we define new exchange again then? And so on?
> > Would'n be better to define XAUTH exchange as open ended?
> >
> > BTW, question to Tim Jenkins. Attribute payload contains
> "Identifier"
> > field. Why not use it (by requiring it to be the same in all
> > attribute payloads during one XAUTH exchange) for state tracking and
> > let M-ID be different (e.g. perform XAUTH as series of ordinary
> > ISAKMP-CFG)?
> >
> > > Jörn
> >
> > Regards,
> > Valery.
> >
>
>
Follow-Ups: