[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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.
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.
"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.
"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?
Regards
Keren & Rakefet