Subject: RE: [Isms] review of draft-ietf-isms-secshell-05.txt

From: "David Harrington" <[email-masked]>
Date: Thu, 10 May 2007 01:39:21 -0400

> -----Original Message-----
> From: Juergen Schoenwaelder [mailto:[email-masked]] 
> Sent: Saturday, November 04, 2006 7:13 PM
> To: [email-masked]
> Subject: [Isms] review of draft-ietf-isms-secshell-05.txt
> 
> I have reviewed <draft-ietf-isms-secshell-05.txt> and below are my
> comments (as a technical contributor).
> 
> /js
> 
> 01: Page 1: Reference [RFC 3411] in the third paragraph in section
1.
Done.
> 
> 02: Page 5: The last sentence in the 3rd paragraph of section 1.3
>     somehow does not read well.
fixed
> 
> 03: Page 5: "User Security Model" -> "User-based Security Model"
fixed
> 
> 04: Page 6: Keyboard-interactive [RFC4256] has been excluded from
the
>     discussion of authentication mechanisms and I think it should be
>     mentioned.
added a reference and a citation in the SSH Protocol overview section.
Do you want more discussion? Can you provide text?

> 
> 05: Page 7: Is the last paragraph on this page needed?
removed.
> 
> 06: Page 8: I think we should replace the term "tunnel" with 
> "channel".
>From RFC4284:    This document describes the SSH Connection Protocol.
It provides
   interactive login sessions, remote execution of commands, forwarded
   TCP/IP connections, and forwarded X11 connections.  All of these
   channels are multiplexed into a single encrypted tunnel."

It looks to me like tunnel is the correct choice. 

> 
> 07: Page 10: "SSH.This" -> "SSH. This"
> 
done.

> 08: Page 10: I think we need to mention here keyboard-interactive
>     again.
done.

> 
> 09: Page 11: Expland "DH" the first time it is used.
done.
> 
> 10: Page 11: The first paragraph in section 3.1.7 actually is part
of
>     an applicability statement and perhaps should be factored out
into
>     a separate section.
done.
> 
> 11: Page 12: I think engineID discovery is so widely used with USM
>     that we can't make the discovery implementation-dependent. We
need
>     an interoperable solution.

engineID discovery is critical to USM because it needs the
securityEngineID. 

> 
>     The USM discovery procedure concerns the securityEngineID (the
>     contextEngineID is actually not passed to a security model). My
>     understanding is that implementations usually do
securityEngineID
>     discovery and subsequently use the securityEngineID also as the
>     contextEngineID (basically assuming that they talk to the
>     non-proxy agent). Please correct me if my assumption is wrong.
> 
>     Dave Perkins wrote a private message on this subject to a few
>     people on Thu, 8 Sep 2005 which led to the conclusion that one
>     should get an snmpUnknownPDUHandlers report if there is not
value
>     engineID (or the PDU type is invalid) and that this can be used
to
>     pickup the "local" engineID. Dave Perkins, can you post the
>     relevant part of your message to this list? [Note that we also
>     discussed this durng the Boston interim.]
> 
>     An alternative approach could be to introduce a "fake"
>     securityEngineID into the Transport Security Model for the only
>     purpose to let it be discovered and to let clients to continue
to
>     assume that the securityEngineID is the contextEngineID to use.
> 
>     Another alternative would be to introduce a general "default"
>     contextEngineID (while conceptually simply and appealing, this
>     does not really work due to the fact the no existing
>     implementation has something like that and all SNMPv3/USM
>     implementations are not likely to change).
> 
     We need to settle on one approach and document it properly.

I do not believe contextEngineID should be discovered by a transport
model or a security model; I believe contextEngineID discovery should
be an application-level function. I believe your discovery document
with a 'local' engineID serves this purpose. 

I eliminated the discovery section, an dall reference to
engineIDnoted.

> 
> 12: Page 13: 1st paragraph in 3.3: Is it OK to be silent how
>     credentials are provisioned?
Provisioning will be at least partly implementation-dependent.

> 
> 13: Page 14: Why do you use the tms prefix here? Note that the names
>     of the transport domain etc. may need to be updated. I am not
sure
>     why you want to have the security model in the LCD.
agreed; I have eliminated securityModel from the document, since the
transport doesn't know about security models.

> 
> 14: Page 16: tmsTransportModel can't be "SSH Transport Model"
removed any reference to
update  transportmodel; since we now use a transportDomain, we don't
need a transportmodel parameter.

> 
> 15: Page 16: Add a comment after tmStateReference in the ASIs.
done.
> 
> 16: Page 17: Add a comment after tmStateReference in the ASI and
>     fix the alignment of the comments.
done.
> 
> 17: Page 18: [todo]: This is mainly an architectural problem since
we
>     can't write the EoP; I assume that in most implementations, you
>     still know whether you send a response or a request. I am not
sure
>     what to do about it. This needs discussion.
need to develop a tmSameSession boolean and EOP to deal with it.

> 
> 18: Page 18: [todo]: I think it is always the client invoking the
>     ssh-userauth service. Shall we state as in step 1) that it is
>     implementation dependent where the parameters are coming from?
done.
> 
> 19: Page 19: drop "(TBD by IANA)"
done.
> 
> 20: Page 19: The last paragraph in 5.3 likely needs updates
depending
>     how we want to deal with engineID discovery. And I kind of
believe
>     we should deal with this in the Transport Security Model, not in
>     every Transport Model.
As mentioned above, I believe this should be an application-level
function, not a transport, message, or security model function.

> 
> 21: Page 19: The first sentence in 5.4 needs a rewrite -
closeSession
>     does not pass data between the Transport Model and the SSH
>     Service.
done.
> 
> 22: Page 21: "SSHTM-MIB" -> "SNMP-SSH-TM-MIB" to be consistent with
>     prior naming conventions. This module should likely be
registered
>     under snmpModules as well.
done.
> 
> 23: Page 23: I am not sure we need TransportAddressSSH; we should be
>     able to use TransportAddressDns.
changed to snmpSSHDomain and SnmpSSHAddress
> 
> 24: Page 24: I think transportDomainSSH should be snmpSshDomain and
be
>     registered below snmpDomains (now that we even have an IANA
>     registry for this).
done.
> 
> 25: Page 24: Does sshtmSessionOpenErrors count all open errors
ranging
>     from TCP connection establishment failures to SSH user
>     authentication failures?
yup.
> 
> 26: Page 24: When will sshtmSessionSecurityLevelNotAvailableErrors
be
>     incremented? Does the document not say SSH is always providing
>     good enough security and we trust it?
yes. removed.
> 
> 27: Page 30: I do not understand the [discuss].
removed.
> 
> 28: Page 30/31: The MIB module security section needs to be updated.
yes; once we stabilize the MIB, I'll update the security cons.

> 
> 29: Page 31: IANA considerations need to be updated (mib-2 ->
>     snmpModules, 
done.
> registration of snmpSshDomain, 
added request to iana considerations

> creation of the
>     transport modules registration is done the transport model
>     architectural extension document.
No it doesn't. The TMSM doesn't require anything of IANA.
We don't register transport models; we define a transport domain for
each transport model.
> 
> 
> -- 
> Juergen Schoenwaelder		    International University Bremen
> <http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 
> 28725 Bremen, Germany
> 
> _______________________________________________
> 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: Thu, 10 May 2007 08:10:46 +0200

> It looks to me like tunnel is the correct choice. 

I believe ISMS runs over an SSH channel, not the underlying encrypted
tunnel.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: "tom.petch" <[email-masked]>
Date: Fri, 11 May 2007 18:11:38 +0200

I have a concern with this I-D that it is blurring the meaning of
authentication  As per RFC2828, there is data origin authentication and peer
entity authentication.  Read the secure session RFC, such as SSH and TLS, and
they are clear that they offer peer entity authentication.and not data origin
authentication.  This I-D, like the RFC341? series, seems to be written as if
there were only data origin authentication, as if authentication was a security
function that will applied to an isolated message, as opposed to occurring only
in the context of an association.  Rather, with Transport Security, the message
cannot be authenticated; it came over a pipe from a peer which was authenticated
some time in the past and the authentication depends on the continued existence
of that pipe.  In security terms, I see the difference as significant and one
that this I-D should call out.

I see this in (at least) 3.2.1.2, 3.2.3 and 3.3.3 .

Tom Petch

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 17 May 2007 18:25:29 -0400

> I believe ISMS runs over an SSH channel, not the underlying encrypted

So do I.  Note that "channel" has specific technical meaning in SSH, but 
"tunnel" really does not - the text you quote from 4284 uses the word in a 
generic sense.

-- Jeff

---

From: "David Harrington" <[email-masked]>
Date: Thu, 17 May 2007 18:57:17 -0400

Thanks for clarifying.
Will fix.

dbh 

> From: Jeffrey Hutzelman [mailto:[email-masked]] 
> Sent: Thursday, May 17, 2007 6:25 PM
> To: [email-masked]; David Harrington
> Cc: [email-masked]; Jeffrey Hutzelman
> Subject: Re: [Isms] review of draft-ietf-isms-secshell-05.txt
> 
> 
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 20 May 2007 21:21:22 +0200

On Fri, May 11, 2007 at 06:11:38PM +0200, tom.petch wrote:

> authentication As per RFC2828, there is data origin authentication
> and peer entity authentication.  Read the secure session RFC, such
> as SSH and TLS, and they are clear that they offer peer entity
> authentication.and not data origin authentication.  This I-D, like
> the RFC341? series, seems to be written as if there were only data
> origin authentication, as if authentication was a security function
> that will applied to an isolated message, as opposed to occurring
> only in the context of an association.  Rather, with Transport
> Security, the message cannot be authenticated; it came over a pipe
> from a peer which was authenticated some time in the past and the
> authentication depends on the continued existence of that pipe.  In
> security terms, I see the difference as significant and one that
> this I-D should call out.

Good point. However, I have the feeling that the SNMPv3 specifications
have never been very consistent about this as they generally promise
data origin authentication but I think data origin authentication is
not what is actually delivered in the case of proxies. Do you agree
with me here?

Still, we can do better and should get the text straight. If you have
concrete proposals how to change the wording in the affected sections,
I am sure Dave will be more than happy to pick them up.

/js

---

From: "tom.petch" <[email-masked]>
Date: Mon, 21 May 2007 09:57:51 +0200

<inline>
Tom Petch

----- Original Message -----
From: "Juergen Schoenwaelder" <[email-masked]>
To: "tom.petch" <[email-masked]>
Cc: "David Harrington" <[email-masked]>; <[email-masked]>
Sent: Sunday, May 20, 2007 9:21 PM
Subject: Re: [Isms] draft-ietf-isms-tmsm-08.txt

> not what is actually delivered in the case of proxies. Do you agree
Yes, I am not sure how I would classify the authentication delivered by
proxies:-)

My main line of thought is to insert a section such as the following - my style
is a little different to yours and those with a greater knowledge of security
than I may want to tweak the terminology - before the existing 3.3.3

===========================================
There are two types of authentication, data origin authentication and peer
entity authentication [RFC2828/draft-shirey-secgloss]. In the former, each
message is individually authenticated using the security credentials.  This
technique is used in SMTP [RFC3851] and in USM [RFC3414];
in fact, parts of the specification of SNMP is written as if this were the only
type of authentication [RFC3411, RFC3412].

With peer entity authentication, the identity of a peer is authenticated, a
secure tunnel (channel, session) is set up with that peer and keying materials
are created for use with that tunnel.  Individual messages may be encrypted or
integrity checked but are not authenticated.  Rather, authentication depends on
the fact that the message arrived over the secure tunnel the endpoint of which
was authenticated when the tunnel was set up, which may be a long time ago. This
approach is used by SSH [RFC4251] and TLS[RFC4346] and so by applications such
as HTTPS [RFC2818] and NETCONF [RFC4742].

The use of transport security by SNMP brings the use of peer entity
authentication and so the wording used by previous documents must be interpreted
in that light.  A Transport Security Model using SSH or TLS  may be able to
check that the tunnel over which a message arrived is known and so that the peer
has been authenticated but cannot meaningfully be said to authenticate an
individual message.  Rather, authentication depends on the procedures followed
when the tunnel was created.

=================================================

In 3.2.1.2, I would put 'authenticate' in quotes with a cross reference to the
above.

In 3.2.3, I would add to the second paragraph a parenthetic comment 'The
different types of authentication are describe in ' with a cross reference to
the above.

In 3.3.3, I would change
"authentication, integrity checking, and encryption services for data"

"integrity checking, encryption and, perhaps, authentication for data".

(After all, the key exchange could derive a key that is used to authenticate
individual messages in addition to the peer entity authentication although I
know of no current system that does so).

Also, in 3.2.1.3, I would change

"establish an authenticated and/or encrypted tunnel between the Transport
Models"
to disallow encrypted unauthenticated which the use of and/or currently permits.

At which point I would re-read the document to see how it all hangs together.

Tom Petch