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

Re: Comments on "Hybrid Auth. mode for IKE"


> 
> Suresh,
> 
> >
> >However, Re-auth does make sense, for example, if the remote site's
> >authentication becomes questionable based on some application specific
> >payload (or) some policy that requires it. But, I digress.
> 
> I think we have another mis-communication here.  IPsec is an Internet layer
> protocol.  When an SA is established it it fixed in its security
> characteristics for the duration of the SA.  There is no notion that a
> specific application payload, sent over an SA, should elicit a different
> set of services.  So, for example, if an application performs some
> operation for which a re-authentication is appropriate, that should be
> provided via an application later security mechanism, not IPsec.
> 

OK, I understand what you are saying. I need to think about this some 
more. I would like to defer this thread on Re-auth to some other time.

> >
> >Well, exchange-type authentication is a strong requirement for legacy
> >verification schemes. To that extent, it is valuable. I was merely
> >extrapolating the process to suggest that we could use the scheme to
> >perform multiple authentications in succession (example - 2 very good
> >methods, one after the other). Apparantly, I have not been able to
> >articulate this well. So, I will drop that line of discussion for the
> >time being.
> 
> A large part of this debate hinges on the desirability of accommodating
> legacy user authentication mechansims in IPsec.  I have no objection to
> this so long as it does not degrade the fundamental level of two-way
> authentication that we get from IKE. I do not agree that the legacy support
> goal is so important that it should cause us to degrade this critical
> security feature.  Look at SSL.  It has a capability for client
> certificates, which provides a user authentication facility analogous to
> what IKE can do for IPsec.  However, most systems are still employing
> static passwords protected by SSL encryption, which results in a number of
> vulnerabilities.  I'd rather not see IPsec fall into the same trap.
> 

The hybrid authentication scheme is not arguing for taking away the 2-way 
authentication scheme. The edge device is still having to authenticate 
itself to remote users (using public key encryption). It is just the 
matter of adapting varying degrees of authentication schemes into the 
protocol for authentication each way.

> >Say, the Certification Authoriy is down for some reason and noone can
> >get certs from there. Wouldnt you agree, it would be a good idea to
> >have a backup authentication scheme in such a case?
> 
> First, one does not retrieve a cert from a CA; one retrieves it from a
> repository of some sort, and such repositories need to be highly available.
> Second, IKE provides a facility to pass certs (and CRLs) as payloads, thus
> avoinding the possibility that an unavailable repository will prevent
> authentication.  In the systems we are engineering based on IPsec, we
> require vendors to make use of this approach, to avoid such problems.
> 

Sounds good. That does not mean other authentication schemes have no place.

> >
> >No argument there. I agree, ISAKMP Authentication is key to ensuring
> >intrinsic authentication to session based SAs. Having said that, I also
> >believe, it is important that people have multiple options to pursue.
> >Let the market place decide what auth. scheme they like in different
> >scenarios.
> 
> Again, a disagreement over goals.  The marketplace has consistently chosen
> weaker security mechanisms in the past.  In creating IPsec the intent was
> to significantly raise the bar, not make minor, incremental improvements.
> 

OK, I will go with that. I have a specific goal to apply current Ipsec
techniques to remote access applications. 

> 
> >Hmm, I am confused. By smart token cards, I am refering to cards like
> >SecurID card. Why should they perform any crypto operations for IKE?
> >SecurID cards do provide 1-way authentication (Card user is authenticated
> >by card verifier). Why should the authentication be 2-way? Each party can
> >be independently Authenticated in a different way, whichever works best.
> 
> Your suggestion is to employ two different authentication methods, one for
> the user and one for the "system."  This requires the user code to be able
> to parse certs and CRLs, so it has many of the capabilities needed for
> support cert-based auth for the user.  Thus the addition of other user auth
> capabilities adds complexity to the user code, increasing the likelihood of
> errors.  That seems to be a downside to this proposal that has not been
> addressed.
> 

I see your clever rewording :-). 
In reality, users dont have certs and there is a strong demand to 
support existing auth.  mechanisms to avail of the IPsec services.

> >
> >I disagree. I dont believe, two-way auth. mechanism has anything to with
> >the strength of authentication.
> 
> Oh come now!  Of course two-way auth is superior to one-way auth, so there
> must be a deeper message you're trying to express here.
> 

I didnt say it right. I was refering to symmetrical 2-way authentication
vs. hybrid 2-way authentication. I was merely saying that the former doesnt
have any intrinsic superiority over the latter. Sorry for the confusion.

> >The market place decides based on multiple criteria including ease of use,
> >security requirements, legacy requirements, cost associated and so forth.
> >For this reason, I would not restrict options to just one kind.
> 
> My comments above about the marketplace stand.
> 
> >
> >Token card based auth. is independent of XAUTH.
> >Token card based auth. simply requires an exchange-type-authentication.
> 
> Perhaps we've gotten confused over terminoloy here.  Let's skip this one.
> 
> 
> >Oops.. I wasnt implying anything different. I guess, I just wanted the
> >word "certificate" spelled out in the sentence :-)
> 
> OK.
> 
> >
> >Say, the user chose an infinite lifetime option. When a user is disconnected
> >from the network, the SAs are presumably still valid, right. In such a case,
> >someone else could get on to the same machine and happily use the session
> >SAs.  By limiting the SA lifetime to "network-connected-time", the SAs
> >automaitcally become invalid when the user is not connected to the network.
> 
> I think you need to explain the assumptions underlying this example.  For a
> remote (dialup) user, when I disconnect from the network, I expect the
> IPsec implementation to clean up and the SA state to go away, thus removing
> any chance of SA reuse. 

Is that a draft requirement? From what I can make out, it is a draft 
requirement to clean up only the retired SAs.  Anyways, thats the idea 
of proposing the network-connected-time metric.

>                         If the disconnect is the result of a crash, I
> expect the state to go away at my end, even though the other end may still
> have SAD entries for the SA(s).  This too renders the SAs useless.  The
> primary circumstance in which your comments seem to apply would be a
> multiuser machine with a faulty IPsec implementation, one that fails to
> maintain the mapping between users and their SAs. In my environment I see
> few (actually, no) such machines, but I agree that under thise
> circumstances, and IF re-auth were employed for extant SAs, then the use of
> a separate user auth method would have some merit.  But, since I am leery
> of actual use of re-auth, and since the example you provided above to
> motivate it had problems, I don't find this a compelling argument. Maybe
> with more detail it would be more persuasive.
> 

I responded to this independently on a seperately e-mail thread to Vipul. 
The basic idea is to allow SAs to remain as long as necessary (given strong
crypto for the SAs) while the remote user is connected. And, when the user
is no longer connected, enforce cleaning up of SAs established.

cheers,
suresh
References: