Subject: RE: [Isms] draft-ietf-isms-tmsm-08.txt

From: "David Harrington" <[email-masked]>
Date: Mon, 25 Jun 2007 19:50:16 -0400

Hi,

>From Tom: "There are two types of authentication, data origin
authentication and peer
entity authentication [RFC2828/draft-shirey-secgloss]."

Actually, there are more than just data origin authentication and peer
authentication. Merriam-Webster defines authentication this way: "to
prove or serve to prove the authenticity of <authenticate a
document>". I added text to the Conventions section that says where
necessary for consistency with related documents, this document favors
terminology consistent with the IETF SNMPv3 Standard (STD62) rather
than the informational 'Internet Security Glossary' (RFC2828).

USM achieved Proposed Standard Status in 1998, Draft Standard status
in 1999, and full Standard status in 2002. In comparison, RFC2828 is
an Informational document, and it was published AFTER USM had already
become a Draft Standard. The IESG decided it was not worth rewriting
all of the RFC341x series to be compatible with RFC2828. Even RFC2828
recognizes that it is using the term authentication in a manner not
consistent with accepted English usage. Don't fault SNMP for using the
accepted English meaning just because RFC2828 decided after the fact
to use the same word to refer to only a subset of the legitimate
usage.

We do not blur the meaning of authentication; RFC2828 does that
disservice just fine on its own. ;-)

In SNMPv3, we "authenticate the message" - we attempt to prove the
authenticity of the message, not just the authenticity of the peer.
In SNMPv3, we authenticate the message partly by authenticating the
principal (the sender of the message, not the sender of the data),
using whatever authentication protocol has been configured to
authenticate that principal. We also verify that the message is
authentic by checking that the message has not been modified, we check
that the message contains a timestamp that is consistent with the
receiver's notion of the time at the message sender (within a time
window) to prevent replay, and for responses, SNMPv3 checks to see
whether we are awaiting a response. All of these go into the SNMPv3
notion of "authenticating the message".

We never explicitly authenticate the data or the original source of
the data; we may assume that the source of the data and the source of
the message are the same when contextEngineID == securityEngineID, but
we never authenticate the contextEngineID, and we do not pass a
contextSecurityName to identify the principal providing the data, and
we provide no mechanisms for authenticating the data contained in the
PDU, only the message that contains the PDU. 

When doing the "proxy forwarder" application described in RFC3413, the
trust relationship is considered transitive, and the PDU (including
the contextEngineID) is never modified by a compliant proxy forwarder.
So, if A has a trust relationship with B, and B has a trust
relationship with C, and C has a trust relationship with D, and each
node verifies the authenticity of the message received from its peer,
then a message from A to B to C to D can be deemed to be "authentic".

In SNMPv3, we deliberately identified the threats that must be
mitigated, but we did not specify HOW different security mechanisms
needed to mitigate the threats; the modular architecture is designed
to permit different security models, and different security
mechanisms, and accepts that different models and mechanisms might
perform threat mitigation in different ways. 

SNMPv3 recognizes two general categories of security services -
authentication of the message, and encryption of all or part of the
message. Verifying the integrity of the message, verifying the
timeliness or in-order-ness of the message, and authenticating the
sending principal are all considered part of "authenticating the
message". 

We want to have the discussions about what threats SSH (or any other
secure transport) should mitigate when used with SNMP, and whether
there are specific operational considerations to ensure that the
threat is not inadvertently not mitigated (e.g., recommend not using
options to not check integrity, or to not authenticate the user).

SSH adequately provides mitigation for the security threats that
RFC3411 identifies as threats to SNMP, even though SSH uses a
different model and mechanisms to provide that mitigation than USM.
SSH authenticates the "user" (the source of the message, not
necessarily the source of the data), and it checks for message
integrity and message replay. It does NOT check for receipt within a
time window (to my knowledge); I believe it requires in-order delivery
to prevent replay. Rather than checking user authenticity for every
message, it performs user authentication once and holds that the
authentication remains true as long as the connection is not
interrupted - i.e., the session exchange hash remains unchanged. 

We do not want to get into discussions of these details of how SSH
works - that should be done by the SSH mechanisms used to provide
"message authentication". The RFC3411 architecture and the SNMPv3
message processing model are pretty clear about the fact they do not
know about the details of the security models or the authentication
mechanisms; the data in the msgSecurityParameters of the SNMPv3
message are only examined by the security model, and it asserts that
the message has been "proved" authentic.

The SSH authentication protocol (RFC4252 "The Secure Shell (SSH)
Authentication Protocol") describes how message authentication is done
- by relying on message integrity and confidentiality services of the
lower layer transport, by using a session hash, and tying the peer
authetication to the session hash. We do not want to prevent the use
of new authentication mechanisms for SSH by over-describing how
"authenticating the message" is expected to be done, or how peer
authentication is performed, or what assumptions are utilized in the
secure transport protocol. We should not add rules to TMSM about the
user authentication being valid only as long as the underlying
transport connection remains; that is a design choice of some secure
transport authentication mechanisms (like SSH-USER-AUTH) that may not
always be true for all secure transport authentication mechanisms in
the future. 

SNMP already has more than enough CLRs without inventing new ones
here.

dbh

> -----Original Message-----
> From: tom.petch [mailto:[email-masked]] 
> Sent: Monday, May 21, 2007 3:58 AM
> To: [email-masked]
> Cc: David Harrington; [email-masked]
> Subject: Re: [Isms] draft-ietf-isms-tmsm-08.txt
> 
> <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
> 
> 
> > On Fri, May 11, 2007 at 06:11:38PM +0200, tom.petch wrote:
> >
> > > 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.
> >
> > 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?
> >
> 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
> 
> > 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
> >
> > --
> > 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/>
> 
> 

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