[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: XAUTH is broken
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.
>
References: