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

RE: XAUTH is broken

Yes I prefer this, if XAUTH wants to use more than one Config exchange than
create a new attribute called

XAUTH_STATE

Set by the initiator and used by both initiator and responder to identify
XAUTH exchanges which span multiple Config exchanges.

The 4 exchange XAUTH is not ideal either, (above attribute would help fix).
If any one has actually used a token card they'll know that it is rather
easy to type in the wrong response, forcing another challenge.  This would
force a new phase 1 (at least how I read the draft) if the first XAUTH
failed, but all you want to do is prompt them again...

Bye.
-----Original Message-----
From: Joern Sierwald [mailto:joern.sierwald@datafellows.com]
Sent: Thursday, July 22, 1999 1:47 PM
To: ipsec@lists.tislabs.com
Subject: Re: XAUTH is broken


At 12:15 22.7.1999 -0400, you wrote:
>Is it broken or not?
>I think we have to come to an agreement very soon if we want people to
>implement xauth and get some interoperability testing in the coming
>bakeoffs.
>
>In previous messages Greg carter has brought up some good points regarding
>the isakmp header message id. Stephane Beaulieu, in a previous message,
>proposed a change in the draft that fixes the problem.
>(section 3: All ISAKMP_Config messages in an extended auth transaction
> will contain same message id...).
>
Stephane did not propose a change, he simply clarified the section.

Again, here is the problem. 
draft-ietf-ipsec-isakmp-mode-cfg-04.txt, chapter 3.1.1:

   As noted, the message ID in the ISAKMP header-- as used in the prf
   computation-- is unique to this exchange and MUST NOT be the same
   as the message ID of another exchange.

And "this exchange" is a config-exchange, which has two packets. Always.

As Grep has pointed out, the cfg-mode draft and the xauth draft 
contradict each other. 

IMHO the cfg-mode draft is fine. The xauth draft is wrong, 
it wants the same message id for several cfg-mode exchanges.
Whats the problem with each cfg-mode having a different id?

tephane and Tim try to change the specs (the cfg-mode)
so that they don't have to change their implementation, 
but I think we should simply delete the
"All ISAKMP-Config messages in an extended authentication
   transaction MUST contain the same ISAKMP-Config message ID."
part from the xauth draft.

---
Jörn Sierwald