[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
FW: Comments on the new Xauth draft
Sorry, forgot to cc ipsec list on the reply.
-----Original Message-----
From: Stephane Beaulieu
Sent: Wednesday, September 15, 1999 12:08 PM
To: 'Rakefet Zadik'
Subject: RE: Comments on the new Xauth draft
> Hello,
>
> After reading the new draft, we have a few unclear points:
>
> "All ISAKMP-Config messages in an extended authentication
> transaction MUST contain the same ISAKMP-Config transaction
> identifier. The Message ID in the ISAKMP header follows the
> rules defined by the ISAKMP-Config protocol."
>
>
> As we understood from the thread held in ipsra, there was a
> trend for making xauth its own exchange (separating it from
> cfg). This draft does not reflect that understanding, furthermore
> this draft seams to force xauth on cfg.
Yes, this was one of the proposals (proposal#2) that Joern had suggested in
his post with subject named "XAUTH is broken", posted on Jul 22 1999. In
the same thread, I had mentioned that I was in favor of this. However, I
received many private emails from implementors who felt that Joern's
proposal#1 from that same email was a better solution (including one email
posted to the list by Tero). To that effect, I sent out another post named
"the next rev of XAUTH" on August 3, 1999, in which I solicited input from
the list on which of the two proposals we should proceed with. Sadly, I
received no emails on the list itself. However, I did receive 3 private
emails supporting Joern's first proposal (as well as Tero's earlier posting
to the list).
>
> The message ID is used as a session identifier through out the
> isakmp protocols.
> Using the identifier as such causes inconsistency and seems
> artificial.
>
> Bonding two cfg transactions for an xauth session requires a
> state machine for the receiver, which is a contradiction to the
> cfg protocol. Now the receiver will first have to verify according
> to the message-id, that the message received is
> not a reply to a cfg it sent. After the decryption, another
> verification according to the identifier will be needed.
>
Your ISAKMP state machine should handle the decryption process based on the
Message ID. After that the isakmp-cfg state machine extracts the
transaction identifier and the message type to determine whether this is a
response or a new exchange.
>
> "If the IPSec host does not have support for the authentication
> method requested by the edge device, then it would send back
> a reply with empty attributes, thus failing the authentication
> but completing the transaction. " -
>
> <draft-ietf-ipsec-isakmp-xauth-05>
>
>
>
>
> "Zero length attribute values are usually sent
> in a Request and MUST NOT be sent in a Response."
> -
> <draft-ietf-ipsec-isakmp-mode-cfg-05>
>
There seems to be a contradiction.
>
Good point. Thanks.
>
>
> "Extended Authentication MAY be initiated by the edge device
> at any time after the initial authentication exchange." - This is
> de facto changing the life duration of the main mode after the
> main mode is finished, why not initiate a new main mode
> instead?
>
Why go through the process of re-doing MM if all you want to do is refresh
user authentication? The reason for adding this is that many authentication
servers allow you to give access to a user for a set period of time. If the
user wishes to extend that time, then he needs to re-authenticate himself.
Thanks for your input,
Stephane.
>
> Regards
>
> Keren & Rakefet
>
>
>
Follow-Ups: