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

From: "tom.petch" <[email-masked]>
Date: Thu, 5 Jul 2007 17:47:48 +0200

David

You make a good argument - but I am not persuaded.  I came across the split of
authentication into two in the context of IETF Security Area WGs and later found
a clear explanation thereof in RFC2858.  Status Informational it may be but it
fits in with what else I see in the Security Area and so, for me, trumps what I
see, perhaps of higher status, from other areas.

And this two-way split makes a lot of sense when I look at what TLS, SSH etc
offer their upper layers as opposed to what SNMP USM or SMTP do.

The issue of what a transport level security authenticates has surfaced before
in isms with, as I recall, concern being expressed that authentication would be
of some transport level entity and not the principal as it is in USM.

So I am not persuaded that transport level security offers message level
authentication.

Tom Petch

----- Original Message -----
From: "David Harrington" <[email-masked]>
To: "'tom.petch'" <[email-masked]>;
<[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, June 26, 2007 1:50 AM
Subject: RE: [Isms] draft-ietf-isms-tmsm-08.txt

> 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
>
>

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