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

RE: New XAUTH draft


>  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.

My point was that the IKE protocol can not restrict this. Only a users
policy can do that. 


>  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.

You have made a leap from using shared pre-shared to using 'public
knowledge' secrets. 

Xauth does not add to the IKE secret state, agreed. IKE auth tells you you
can trust a device at the other end of the tunnel, and xauth allows you to
control which users of that device are allowed access.  

Xauth using certain legacy systems (e.g. SecureID) does offer some of the
features of certificate Smartcard without the need to require PKI. Migration
is an important customer requirement. It may not add to the IKE secure
state, but it does add security confidence that the client actually has the
required token card and knows the pin number, but let's not go down that one
again.


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

I don't want to do anything (usually). To try and focus on the common
ground, I agree that pre-shared should be used only when PKI is not
acceptable to some customers, and that per-user pre-shared with all the
precautions we can list should be recommended. I don't agree that sharing
pre-shared by more than one device should be out-lawed. 

Steve.

>  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: 
> 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.