[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
the next rev of XAUTH
Hi All,
Sorry to keep bringing XAUTH up, but I just want to make sure everyone is in
agreement before we proceed.
A few weeks ago, there was a thread going on about modifying XAUTH to make
it's state machine cleaner. I asked for comments and got quite a few, both
private and public. I'd like to resolve this ASAP so that vendors who are
interested in doing XAUTH can test interop at the next bakeoff. I've
narrowed it down to 2 proposed changes which have both received a fair
amount of support, and I'd like to get input as to which we should push
forward. I would really like to hear from those who have already
implemented, and who plan on implementing this in the near future on which
proposal they prefer.
Proposal 1: Use a new Exchange ID for XAUTH, with the same Isakmp Message
ID, and XAUTH identifier throughout the transaction.
Pros:
- Easier to make the IKE state transitions because it is easier to tell
whether we're really doing XAUTH or IKE-Config (we don't have to look inside
the packet to figure it out)
- State machine for Isakmp Processing is simple: if it is an IKE-Config
exchange it is 2 messages, if it is an XAUTH exchange it is multiples of 2,
until STATUS and ACK are done, then you can clean up your states.
Cons:
- Will have to use a new ISAKMP Exchange ID (240?), this will cause problems
for those with an implementation already out there.
- Exchange ID will change once/if XAUTH becomes an RFC, this means that
we'll have to switch the Exchange ID once again and use Vendor ID payloads
to maintain backwards compatibility.
- Code re-use isn't as easy, because XAUTH and Ike-Config would have
different behaviors.
Proposal 2: Use IKE-Config as a transport (as it is today) but force the use
of a new Isakmp Message ID for each REQUEST/REPLY, SET/ACK pair, and keep
the identifier in the Ike-Config attribute payload consistent for all the
XAUTH messages.
Pros:
- State machine for Isakmp Processing is simple: an IKE-Config transaction
is always 2 messages.
- Code re-use is much easier; little code needed to write new code if you
already have Ike-Config
- the Isakmp Exchange ID is more likely to remain as it is today (no
backwards compatibility issues in the future)
- Easier transition for those who already have XAUTH implemented.
Cons:
- Your IKE state machine doesn't know what it is processing (Ike-Config, or
XAUTH) unless it looks inside the Ike-Config message or is notified by some
other handler.
Again, I'd like to get this resolved in the next 2 weeks, so if you've got
an opinion on this matter, speak up now. Let me know what it is that you
prefer.
Thanks,
Stephane.
Stephane Beaulieu TimeStep Corporation
sbeaulieu@timestep.com http://www.timestep.com
(613) 599-3610 x4709 Fax: (613) 599-3617