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

Re: New XAUTH draft



Dan, I understand what you are getting at, but I don't think it's XAUTH 
responsibility to mandate that a shared secret be truelly secret.  I would 
like to see XAUTH be secure, but not be limiting.  Not everyone has the same 
paranoia level, and thus the customer needs to make up their own mind about 
just how secure they need something to be.  If they are foolish enough to 
spread a single "shared secret" around them, it is their own fault.  Yes, we 
can place a lot of wording in our documents about the dangers about this 
scenario, but we can't prevent it from happening accidentally, or on 
purpose.


>From: Dan Harkins <dharkins@network-alchemy.com>
>To: "Waters, Stephen" <Stephen.Waters@cabletron.com>
>CC: ipsec@lists.tislabs.com
>Subject: Re: New XAUTH draft
>Date: Thu, 30 Sep 1999 09:12:45 -0700
>
>   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.

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com