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

Re: New XAUTH draft





Dan Harkins wrote:

>   Stephane, Roy,
>
>   I have some suggested text for the new XAUTH draft (-05.txt).
>
> Section 2 (Extended Authentication Model) includes this:
>
>    The Extended Authentication mechanism does not replace the IKE
>    Phase 1 authentication mechanisms.  It simply extends them by
>    allowing devices to do two different authentication schemes.  Both
>    peers SHOULD still authenticate each other via the authentication
>    methods described in [IKE].
>
> This really has to be a MUST. There is absolutely no reason why the IPSec
> WG (which is, after all, in the Security Area of the IETF) should allow
> an unauthenticated key exchange. Also, the mechanism described in this
> draft does not effect the authenticated status of the IKE SA in any way.
> It is not an extension of it as it does not add anything to the security
> of the IKE exchange. I suggest changing this to:
>
>    The Extended Authenticated mechanism does not effect the authenticated
>    nature of a phase 1 security association in any way. Both peers MUST
>    authenticate each other via the authentication methods described
>    in [IKE]. There are Security Considerations involved in one of the
>    authentication methods in [IKE] and this is described in section 6.
>
> Secction 6 (Security Considerations) includes this paragraph:
>
>    The use of Extended Authentication does not imply that phase 1
>    authentication is no longer needed. Phase 1 authentication provides
>    a higher level of user authentication by signing ISAKMP packets.
>    Extended Authentication does not provide this service.  The removal
>    or weakening of phase 1 authentication would leave the IPSec
>    session vulnerable to a man-in-the-middle attack and other spoofing
>    attacks.  Therefore, when using Extended Authentication with Pre-
>    Shared keys, it is vital that the Pre-Shared key be well chosen and
>    secure.
>
> which severely understates the purpose of IKE authentication and goes
> on to assume a "well chosen" pre-shared key is appropriate for phase 1
> authentication.
>
>   Authentication of the IKE SA is not just for "signing ISAKMP packets."
> It is what binds the peers to their keying material and therefore what
> makes the resulting IPSec SAs authenticated. Without true authentication
> of the phase 1 SA the IPSec SAs are esentially unauthenticated. This can
> happen when one uses pre-shared key authentication with remote-access
> clients whose IP addresses cannot be know a priori.
>
>   I would like to see that complete paragraph replaced with this:
>
>     As mentioned in section 2, the protocol described in this memo does
>     not effect the authenticated nature of the phase 1 security association
>     in any way. An unauthenticated phase 1 security association could only
>     create unauthenticated phase 2 security associations (e.g. IPSec security
>     associations) regardless of the presence or absence of this protocol
>     between a phase 1 and phase 2 exchange.
>
>     Due to restrictions in [IKE] regarding the use of Main Mode and
>     pre-shared keys this protocol MUST NOT be used with [IKE] when
>     doing Main Mode and pre-shared key authentication. Further, it MUST
>     NOT be used with any key exchange protocol in which the parties
>     to the exchange authenticate each other using a "group" pre-shared key
>     (i.e. one that is shared by more than the two parties to the exchange).
>
>   thanks,
>
>     Dan.

I agree with your disapproval of the use of a key shared by more than two parties
during Phase 1.
This kind of modus operandi is even worse than standard pre-shared key
authentication which is already weak.

However, I do not think we need to mandate that Phase 1 authenticates both
parties:
For protection against man in the middle attacks it is sufficient for only one
peer to be authenticated.
For the remote user to trust the security gateway before divulging his
credentials in XAUTH it is sufficient that the
edge device is authenticated.
Therefore, it seems that the demand for mutual Phase 1 authentication prior to
XAUTH can be relaxed and replaced with
the demand that only the edge device be authenticated.
While asymmetric Phase 1 authentication with pre-shared keys seems unreasonable,
the draft must not rule out asymmetric Phase
1 authentication using signatures.

Regards,
Tamir.





References: