Subject: Authentication Binding (was RE: [Isms] Rough Consensus Declaration: ISMS Architecture is EK)

From: "Khanh Nguyen \(khanhvn\)" <[email-masked]>
Date: Thu, 5 May 2005 18:33:15 -0700

> -----Original Message-----
> From: Sam Hartman
> 
> >>>>> "McDonald," == McDonald, Ira <[email-masked]> writes:
> 
>     McDonald,> Hi, It's failing because of the man-in-the-middle
>     McDonald,> attacks with freely available hacker tools.  If the
>     McDonald,> authenticated security identities of both parties are
>     McDonald,> not bound into the same protocol layer, then
>     McDonald,> man-in-the-middle attacks are easy.
> 
>     McDonald,> This has been noted in the past on the ISMS WG mailing
>     McDonald,> list, but I wanted to remind people again not to make
>     McDonald,> this mistake.  This is specifically why using HTTP
>     McDonald,> Digest for client auth after doing server auth at the
>     McDonald,> TLS layer is inherently unsafe (as I'm sure you know).
> 
> So, I really hate to be defending this practice as I'm 
> normally the one who is decrying the practice of not binding 
> authentication.
> However SASL doesn't currently provide a way of binding 
> authentication to TLS.  So if we support SASL, then we are 
> vulnerable to this issue.

We can use TLS built-in password auth methods (e.g. TLS-SRP or
draft-ietf-tls-psk-07.txt) instead of SASL.  Binding will be 
done transparently by TLS.  The disadvantage of this is that 
SNMP auth will be tightly coupled with a specific transport.

Using SASL makes authentication more transport-independent, but 
some binding will need to be done, as Juergen S. pointed out 
earlier.  draft-puthenkulam-eap-binding-04.txt has some good 
discussions about the solutions for this.

> 
> Note that it is not actually a problem if you verify TLS certificates.

I agree.  Once you can bind the server auth to the session,
there is no need to bind the client because man-in-the-middle 
attacks require fooling both sides.  IMHO, the problem w/ 
asymetric auth is not really about security (if done properly),
but rather about the difficulty to deploy/manage server 
credentials (e.g. certs) in distributed environments such as SNMP.

Khanh

> So it's not so much that you are vulnerable to a 
> man-in-the-middle attack as that you need to deploy a 
> different authentication infrastructure for client to server 
> than for server to client.  If both of these infrastructures 
> work ande are correctly configured then things are secure.
> 
> At one level I think that is a bad design and hope not to 
> repeat the mistake in future protocols.  To the extent that 
> it is reasonable to do I'll make sure that ISMS does not make 
> this mistake.
> 
> At another level, though, many people do want the combination 
> of SASL and TLS.  It is sometimes a bigger mistake to prevent 
> people from using their deployed infrastructure.
> 
> 
> _______________________________________________
> Isms mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/isms
> 

_______________________________________________
Isms mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isms