[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: XAUTH?



Greg,

1. Why do you want to distinguish a config mode exchange and
    XAUTH ?

    I think the problem starts with the absence of a clear definition of  the
    'Extended Authentication Method' (XAUTH) in the draft. If we define it as
    "a sequence of 1 or more config mode exchanges, initiated by an edge device to
     a host until the host is authenticated or rejected" then everything is fine.
    The 'responder'  always expects a next config mode exchange until it receives
    the SET(STATUS=OK or NOT OK) message. The SET message is really the
    criterion that the responder uses to stop waiting for a message. When the responder
    sends the ACK then that is the end of the XAUTH session.

2. You don't want to limit the messages to 4, because i may want to do try
    a sequence of authentication types one after the other. So it is not necessarily
    negative that there is no limit the way it has been defined.

   yannis


Greg Carter wrote:

> 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?
> <>
> <>
> <>
> <>
> <>
> <

--
Ioannis Bonias, PhD
Axent Technologies, INC. /Raptor Division
email : ibonias@raptor.com
phone : 781.530.2359
fax   : 781.487.9372




References: