[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
FW: XAUTH?
I sent this yesterday, doesn't seem to have made it to the list.
-----Original Message-----
From: Greg Carter
Sent: Thursday, July 15, 1999 2:55 PM
To: 'Stephane Beaulieu'; Andrew Krywaniuk; 'ipsec@lists.tislabs.com'
Subject: RE: XAUTH?
Hi, Stephane,
Yes it makes it clear, however it is broken.
Config Mode is defined as a two packet exchange, then you can delete state.
Now I have to determine is this is an XAUTH config mode? or is it just a
regular config mode?, if it's xauth then wait for some more and save state.
This isn't at all consistent with other IKE exchange types. All IKE
exchanges types currently have a defined packet sequence, xauth changes that
to "config is two but if this bit is set in an attribute payload then what I
really want to do is something completely different with four."
If you are going to make XAUTH a 4 sequence exchange then why not define a
new exchange type, since it really has nothing to do with config?
Especially since it breaks any generic config mode implementations would
expect the 3rd sequence to be a new Config mode.
Thanks
Bye.
-----Original Message-----
From: Stephane Beaulieu [mailto:sbeaulieu@TimeStep.com]
Sent: Thursday, July 15, 1999 4:38 AM
To: Andrew Krywaniuk; Greg Carter; 'ipsec@lists.tislabs.com'
Subject: RE: XAUTH?
Hi Greg,
I guess there is some ambiguity. The text in the next rev.
will be clarified.
in section 3, the following text
All ISAKMP-Config messages in an extended authentication
transaction MUST contain the same ISAKMP-Config message ID.
Will be changed to
An extended authentication transaction is defined as a series
ISAKMP-Config messages.
All ISAKMP-Config messages in an extended authentication transaction
MUST contain the same ISAKMP-Config Identifier as well as the same
ISAKMP Message ID and continue to chain the IV for all messages in
the transaction.
Does this clarify things?
Stephane.
<-----Original Message-----
<From: Andrew Krywaniuk [mailto:akrywaniuk@TimeStep.com]
<Sent: Wednesday, July 14, 1999 4:40 PM
<To: Greg Carter; 'ipsec@lists.tislabs.com'
<Subject: RE: XAUTH?
<
<
<It seems that we have a keyword overloading problem here, as the word
<transaction is used in two different contexts:
<
<A "configuration transaction" is a pair of messages wherein a set of
<attributes is proposed (message 1) and then these attributes
<either accepted
<or rejected (message 2).
<
<An "XAuth transaction" is a series of ISAKMP-Config messages
<which leads to
<the user being accepted or rejected.
<
<Once you resolve the meaning of the word "transaction," I
<don't think it's
<implied that each configuration transaction has to have a
<different message
<id. The XAUTH draft is correct in stating (indirectly) that
<the message id
<has to remain the same across multiple configuration transactions.
<
<Andrew
<_______________________________________________
< Beauty without truth is insubstantial.
< Truth without beauty is unbearable.
<
<
<> -----Original Message-----
<> From: Greg Carter [mailto:greg.carter@entrust.com]
<> Sent: Wednesday, July 14, 1999 2:09 PM
<> To: 'ipsec@lists.tislabs.com'
<> Subject: XAUTH?
<>
<>
<> Hi,
<>
<> Config Mode states:
<>
<> "A "Configuration Transaction" is defined as two configuration
<> exchanges, the first being either a Set or a Request and
<the second
<> being either an Acknowledge or a Reply, respectively.
<>
<> ...
<> Transactions are completed once the Reply or Acknowledge code is
<> received."
<>
<> To me this means that the message ID is unique for the
<> transaction, either a
<> Set-Ack or Request-Reply pair.
<>
<> However XAUTH states:
<> All ISAKMP-Config messages in an extended authentication
<> transaction MUST contain the same ISAKMP-Config message ID.
<>
<> And gives examples where a Request-Reply is followed by a
<> Set-Ack and is
<> referred to as a "transaction".
<>
<> Are the message ID's unique for the Request-Reply and Set-Ack
<> in XAUTH or
<> are they the same?
<>
<>
<>
<>
<>
<