Subject: RE: [Isms] #2: is server authentication a requirement that SNMP willrequire

From: "Kaushik Narayan \(kaushik\)" <[email-masked]>
Date: Fri, 14 Oct 2005 08:59:44 -0700

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of David B Harrington
Sent: Thursday, October 13, 2005 2:46 PM
To: [email-masked]
Subject: [Isms] #2: is server authentication a requirement that SNMP
willrequire

#2: a) is server authentication a requirement that SNMP will require of
the client? 

I think this is an artifact of any TMSM, I don't think we really have an
option. We will have to support it.

	b) how can we verify that server authentication was performed,
or do we take simply trust the SSH client layer to perform such
authentication?

We have to trust the SSH layer. Any  TMSM not just SSHSM will need to
trust the transport layer to perform server authentication and key
negotiation.

	c) for the common case of DH signed by public keys, how does the
client learn the host's public key in advance, and verify that the
correct key is being used?

I had mentioned this in a previous note, SSHSM does create the need to
manually provision public keys on clients until we have X.509 support
(or GSSAPI is being used). SSH client implementations in interactive
mode will verify the key by echoing it to the user  and saving the key
once the user accepts. We cannot do that with SSHSM and we either
require manual provisioning of server public keys or accept blindly the
first time, which make it suscepitble to mitm.

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

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 17 Oct 2005 13:29:19 +0200

> first time, which make it suscepitble to mitm.

Management applications at the very end also have a human being
involved. I don't see a reason why a management application can't do
the same as my ssh client does when you hit a box you have not talked
to before. Initiate a dialog with a human decision maker, open a
ticket in a trouble ticket system or whatever the app writer seeks
appropriate to get an OK to accept the key. This is all implementation
detail for me.

The spec should just say somewhere (perhaps in the security
considerations section) that public host keys must be verified to
prevent mitm attacks and that applications should cache host keys and
warn about any changes. It is likely that all this text has already
been written and we can just refer to the appropriate section(s) in
the ssh documents.

I think we should not even try to standardize a way to automatically
verify host keys. If there is a need for such a feature, I think the
ssh WG should work a general solution since this problem is not ISMS
specific.

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

---

From: Eliot Lear <[email-masked]>
Date: Mon, 17 Oct 2005 17:41:17 +0200

I largely agree with what Juergen says but I'd suggest that we should 
anticipate X.509 certs being available in SSH.  Imagining this being the 
case, how does that change the situation wrt host keys?

Eliot

---

From: Sam Hartman <[email-masked]>
Date: Mon, 17 Oct 2005 18:19:14 -0400

>>>>> "Eliot" == Eliot Lear <[email-masked]> writes:

    Eliot> I largely agree with what Juergen says but I'd suggest that
    Eliot> we should anticipate X.509 certs being available in SSH.
    Eliot> Imagining this being the case, how does that change the
    Eliot> situation wrt host keys?

I'd advise against assuming there will be a big push for ssh x.509
certs.  It probably will be standardized; some people will probably
implement it.  However one of the major attractive features of ssh is
that it does not use x.509.

---

From: Eliot Lear <[email-masked]>
Date: Tue, 18 Oct 2005 06:14:02 +0200

> that it does not use x.509.

Sam, what you see as attractive is also a scaling limitation.  It's easy 
for us to ship a core set of PCA certs in a device.  Think about this 
way.  My aunt goes to her local supermarket to buy a new set top box 
that she wants to use with her service provider, who will give her a 
username and a password.  You want her to be sure that her device 
authenticates the configuration server.  How is she supposed to verify 
that the host key is the right one?

This is why it's important for X.509 certs to be done.

Eliot

---

From: Sam Hartman <[email-masked]>
Date: Tue, 18 Oct 2005 10:06:44 -0400

>>>>> "Eliot" == Eliot Lear <[email-masked]> writes:

    Eliot> Sam Hartman wrote:

    Eliot> Sam, what you see as attractive is also a scaling
    Eliot> limitation.  

I don't see it as attractive.  Our community of users--the people who
use our protocols--see it as attractive.

I find it really annoying.  I mostly avoided ssh until the gssapi
support became stable basically for the reasons you describe.

    Eliot> It's easy for us to ship a core set of PCA
    Eliot> certs in a device.  Think about this way.  My aunt goes to
    Eliot> her local supermarket to buy a new set top box that she
    Eliot> wants to use with her service provider, who will give her a
    Eliot> username and a password.  You want her to be sure that her
    Eliot> device authenticates the configuration server.  How is she
    Eliot> supposed to verify that the host key is the right one?

First, leap of faith (trust the first hostkey you get) probably would
be sufficient for this situation.

Second, I do understand the value of PKI.  I understand that in some
environments it will be used.  ISMS needs to support that.

But the charter goal of ISMS is to work with authentication people use
today.  Today, people do not use X.509 with ssh.  No matter how much
you, I or anyone else wants them to, it simply is not what people
currently do.  So, while ISMS should support it, and while you can
(and should when appropriate) sell products that rely on it, it cannot
be our primary focus.

--Sam