Subject: [Isms] ISMS #5: dual authentication issues

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 23 Jan 2008 21:47:57 +0100

ISMS #5: dual authentication issues
Status: open

Dave Harrington wrote:

    dual authentication issues

This issue requires better explanation. I assume it is about what
happens if you run for example SNMPv3/USM over SSHTM.

Q5.1: Is the issue well stated?

Q5.2: What are the possible solutions and their pros/cons?

/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

---

From: "David Harrington" <[email-masked]>
Date: Wed, 23 Jan 2008 16:41:02 -0500

Hi,

Yes, this issue is about using two different authn mechansims for the
same message. The SNMP architecture, and the ASIs, assume you will use
only one protocol to authenticate a principal. With secure transport
AND a security model, we end up with problems.

One issue is which authenticated identity is used for access controls?
Our current solution is to make the "inner-most" authentication (e.g.,
the one specified in the SNMP message) the one that sets the
securityName for use with access control. That is consistent with
RFC3412 and RFC3584, which says the security model is chosen by the
message processing model.

A second issue is whether, for a message to be secured by both USM and
transport security (SSH), the engine knows which credentials to use
for the USM security and which for the transport security, since the
ASIs do not provide both.

dbh

> -----Original Message-----
> From: Juergen Schoenwaelder 
> [mailto:[email-masked]] 
> Sent: Wednesday, January 23, 2008 3:48 PM
> To: [email-masked]
> Subject: [Isms] ISMS #5: dual authentication issues
>

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 23 Jan 2008 17:04:18 -0500

> message processing model.

I think this is the correct answer.  Under the SNMPv3 architecture (which I 
don't believe we are not empowered to change), the only way transport 
security gets its foot in the door is through the use of the transport 
security model.  If some other security model is used, then transport 
security is completely irrelevant, except that if you try to use it and get 
it wrong, then things will probably not work. :-)

> ASIs do not provide both.

If the transport security model is not used, there is no binding between 
transport security and the authenticated identities used for access 
control, so I don't think the message can truly be said to be "secured" by 
transport security.

As I understand it, the ASI's provide only the securityName; the actual 
underlying credentials (USM keys, Kerberos keys, certificates, etc) used 
are obtained in a fashion that is at least partly implementation-dependent.

I don't think we need to describe how to send messages using transport 
security along with a non-transport security model.  Even if we choose to 
permit this behavior, I don't think we need to describe how to make it work 
when the credentials are not the same.  The fact that it works at all on 
the receiving side is more an indication that we haven't broken the 
abstraction than an actual goal in itself.

-- Jeff

---

From: "David Harrington" <[email-masked]>
Date: Wed, 23 Jan 2008 17:25:29 -0500

So you favor adding text that says when using a secure transport
model,  the security model field in the SNMPv3 message MUST be set to
TSM?

or is it text that says if you are using a non-transport security
model, such as the community security model, then you MUST NOT (SHOULD
NOT) use a secure transport model?

That would imply the (possibly already existing) module which
constructs the message must now know which transport model is being
used, and whether it is secure, and error out under some conditions.
Would that violate architectural modularity?

dbh

> From: Jeffrey Hutzelman [mailto:[email-masked]] 
> Sent: Wednesday, January 23, 2008 5:04 PM
> To: David Harrington; [email-masked]
> Cc: [email-masked]
> Subject: RE: [Isms] ISMS #5: dual authentication issues
>

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 23 Jan 2008 17:50:02 -0500

> Would that violate architectural modularity?

That's a good question.  Conceptually, I do not oppose a requirement that 
TSM and secure transport models be used together or not at all.  From a 
practical standpoint, I don't think it's very difficult for operators to 
understand that, and I would actually expect the tools that configure such 
things to conflate the two, such that you are offered the choice of using 
USM or SSH (or possibly, USM/UDP, USM/TCP, or SSH).  However, it likely 
would break modularity and be a significant burden for the application to 
verify that this rule is followed (the application can know what transport 
model is in use, because this is inherent in the transport mapping, yes?).

One concern I do have is that when sending a message, we must not use TSM 
without a secure transport model, because that would result in sending an 
unproctected message, possibly when the application thinks it has asked for 
confidentiality.  We should make sure this cannot happen.

I think we've agreed that we want to be able to use a secure transport 
model with SNMPv1/SNMPv2c, and that doing so probably requires modifying 
the EoP such that when you use a secure transport, you magically get TSM 
instead of the community security model.

-- Jeff

---

From: "tom.petch" <[email-masked]>
Date: Fri, 25 Jan 2008 15:47:42 +0100

----- Original Message -----
From: "Jeffrey Hutzelman" <[email-masked]>
To: "David Harrington" <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, January 23, 2008 11:50 PM
Subject: RE: [Isms] ISMS #5: dual authentication issues

> instead of the community security model.

Going back to the original question, then dual authentication per se is a good
thing and, in a wider context, is becoming a requirement for high security
systems (eg high finance).  What matters is that the credentials all
authenticate one and the same identity (principal) for the message and as long
as it is clear who/what that principal is (and other issues
have raised concerns about that), then it should not matter how many times we
authenticate.

Tom Petch

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 29 Jan 2008 17:01:53 -0500

--On Friday, January 25, 2008 03:47:42 PM +0100 "tom.petch" 
<[email-masked]> wrote:

>> understand that, and I would actually expect the tools that configure
>> such things to conflate the two, such that you are offered the choice of
>> using USM or SSH (or possibly, USM/UDP, USM/TCP, or SSH).  However, it
>> likely would break modularity and be a significant burden for the
>> application to verify that this rule is followed (the application can
>> know what transport model is in use, because this is inherent in the
>> transport mapping, yes?).
>>
>> unproctected message, possibly when the application thinks it has asked
>> for confidentiality.  We should make sure this cannot happen.
>>
>>
> Going back to the original question, then dual authentication per se is a
> good thing and, in a wider context, is becoming a requirement for high
> security systems (eg high finance).

No.  What is becoming a requirement is two-factor authentication, wherein a 
user proves his identity to the system using two distinct "factors", such 
as a physical token plus a PIN or password.  This is not the same as a 
client authenticating to a network service using multiple authentication 
protocols, which to date I have not heard of anyone requiring.

Note that using TSM with SSHTM where initial authentication is to the SSH 
server, it is possible to obtain two-factor authentication by using SSH 
userauth methods such as keyboard-interactive, or by combining multiple 
methods, such as password along with publickey where the corresponding 
private key is known only to a smartcard.  One can also use GSS-krb5 with 
tickets obtained through a two-factor process.  The key property is not the 
use of multiple protocols, but the use of multiple factors (secrets or 
physical objects or attributes) by the human user to prove his identity.

So no, there is no security reason to run USM-over-SSH or the like; the 
ability to do so is valuable primarily as an indication that we haven't 
broken an abstraction we shouldn't.  We have discussed supporting 
SNMPv1/v2c over SSH; in those cases SSH would be the _only_ source of 
authentication, and TSM the only security model in use; the community 
security models normally used with these MPM's would be ignored.

-- Jeff

---

From: "David Harrington" <[email-masked]>
Date: Tue, 29 Jan 2008 20:52:45 -0500

Hi,

> Sent: Tuesday, January 29, 2008 5:02 PM
> To: tom.petch; David Harrington; [email-masked]
> Cc: [email-masked]
> Subject: Re: [Isms] ISMS #5: dual authentication issues
> 
[...]
> protocols, which to date I have not heard of anyone requiring.

I knew there was another dual-XXXX name for what Tom was referring to,
but couldn't place the dual-factor terminology.

> broken an abstraction we shouldn't.  

> We have discussed supporting 

Currently, the SNMPv1/v2c community would be the only source of
authentication recognized when doing access control for requests
carried by v1/v2c messages, because the Informational RFC3584
hardcodes CSM as the security model for v1/v2c messages.

The WG has not reached consensus to support SNMPv1/v2c/v3/v99 over
SSH, by allowing selection of TSM rather than CSM as the security
model when there is a secure transport.

(I am in favor of such a change).

dbh

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 29 Jan 2008 21:02:48 -0500

> model when there is a secure transport.

Right; what I described is what would happen if this approach were adopted. 
Of course, if we choose not to support v1/v2c over SSH, then the point is 
moot.  We could also choose to permit the use of the SSH transport model 
with these versions, but _without_ changing the way the security model is 
selected.  The result is that the secure transport would be present, but 
would not have any effect on security parameters.  This is similar to what 
I would expect with SNMPv3+SSHTM+USM; since TSM is not used the secure 
transport has no effect on security parameters or access control.

-- Jeff

---

From: "Bert Wijnen" <[email-masked]>
Date: Wed, 30 Jan 2008 11:09:32 +0100

W.r.t.
> (I am in favor of such a change).

The fact that SNMPv1/v2c use CSM is (I believe) completely described
in RFC3584, which is a BCP (dated Aug 2003).
Of course, at that time, given the state of SNMP in general, that was
more or less the only BCP we could think of.
I can imagine, that as soon as we have SNMP (any version) over SSH,
that we could update the BCP to indicate that a better parctice
(in 2008) would be to use SSH and TSM and fit SNMPv1/v2c into the
current SNMP secure environment.

So it could be done by opening up RFC3584. 
Is that so problematic?

Anyway, I am also in favor of such a change.

Bert

---

From: "Donati Andrew-MGIA0477" <[email-masked]>
Date: Thu, 31 Jan 2008 10:25:10 -0500

>From: Bert Wijnen [mailto:[email-masked]] 
>Sent: Wednesday, January 30, 2008 5:10 AM
>To: David Harrington; 'Jeffrey Hutzelman'; 'tom.petch'; [email-masked]

>The fact that SNMPv1/v2c use CSM is (I believe) completely described in
RFC3584, which is a BCP (dated Aug 2003).
>I can imagine, that as soon as we have SNMP (any version) over SSH,
that we could update the BCP to indicate that a >better parctice (in
2008) would be to use SSH and TSM and fit SNMPv1/v2c into the current
SNMP secure environment.
>Anyway, I am also in favor of such a change.

I am also in favor of such a change and am in favor of updating the
latest version of 
"Coexistence between Version 1, Version 2, and Version 3 of the
Internet-standard Network Management Framework",
currently RFC3584.

Andy