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

Re: New XAUTH draft



  It's not the distribution of the group pre-shared secrets that's the
problem (remember MKMP? That was a marvelously secure, simple (3 messages), 
and mutually authenticated way to distribute a group secret. I also 
remember people screaming "but if more than two people know the secret
then it isn't a secret anymore."). It's that you lose authentication that 
way. draft-ietf-ipsec-internet-key-01.txt was an April Fools draft but 
the security considerations of that were very real. Unfortunately that 
draft expired so let me quote it:

   The use of pre-shared keys has known security implications. When used
   for authentication, the presentation of a shared secret is proof of
   identity.  When used for datagram authentication, the pre-shared key
   authenticates the content and source of the datagram.  Using the
   Pre-Shared Key for the Internet will, in effect, allow you to
   authenticate everyone.  One drawback is that this will negate the
   effects of all related security protocols.

  It might "make no difference to IKE" if you use the pre-shared key for 
the internet in doing IKE but that is just plain stupid. And, yes, it can
restrict it by simple MUST NOT verbage. That's the whole point.

  Since XAUTH provides _absolutely_ _no_ _additional_ _security_ to the
IKE secret state what you're ending up with is unauthenticated IPSec SAs!
There's no way that the customer can manage this. It just plain doesn't
work.

  If you want to do things insecurely then make up a simple insecure
unauthenticated key exchange and do XAUTH on top of that. 

  Dan.

On Thu, 30 Sep 1999 14:33:26 BST you wrote
> I'm not suggesting that anyone should be happy with insecurity. My point was
> that there are ways to make the distribution of group pre-shared secrets
> secure, and if that is the policy adopted by a customer, the protocol should
> not prevent that.
> 
> I am not saying pre-shared is 'great', and group-pre-shared is obviously n
> times more risky, but if the customer manages these risks effectively, the
> choice is his.
> There is no difference to the IKE protocol which is used, so it has no
> business (IMHO) mandating one over the other, and has no way of restricting
> it anyway.
> 
> I think this is a small issue of wording. I'm agreeing that recommendations
> could be made and discussed in the draft.
> 
> Cheers, Steve.
> 
> -----Original Message-----
> From: Dan Harkins [mailto:dharkins@Network-Alchemy.COM]
> Sent: Wednesday, September 29, 1999 9:55 PM
> To: Waters, Stephen
> Cc: ipsec@lists.tislabs.com
> Subject: Re: New XAUTH draft 
> 
> 
>   A policy decision? I guess everything could be called a policy decision
> but we're trying to build _secure_ protocols here. No one is being stopped
> from doing something insecure. If they're happy with insecurity (e.g. if
> they have a stated policy that an unauthenticated Diffie-Hellman is fine) 
> they can do it without IKE. And there are other examples of mandating secure
> 
> behavior (which could easily be called "a policy decision") in our various 
> documents so I don't see this restrictive.
> 
>   What do you gain by allowing patently insecure use of a security protocol?
> 
>   Dan.
> 
> On Wed, 29 Sep 1999 13:36:53 BST you wrote
> > 
> >     "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)."
> > 
> >   
> > Dan,  I think this is too restrictive.  What if I decide to use
> > main-mode/pre-shared for device level authentication, and XAUTH for
> > user-level authentication?
> > 
> > Also, the part about using a "group" pre-shared key is a policy decision,
> in
> > my view.  If the user/manager is happy with the security policy protecting
> a
> > "group" pre-shared key, that should be his policy decision, not ours.  It
> > may be worth some text in the 'Security Considerations', but I don't think
> > this should even be a "SHOULD" in the protocol itself. 
> > 
> > Cheers, Steve.


Follow-Ups: References: