Subject: [sacm] Combining "User" and "Credential" into "Account"

From: "Kahn, Clifford" <[email-masked]>
Date: Sun, 9 Nov 2014 15:50:54 +0000

Hello all.

draft-ietf-sacm-information-model-00, section 4.2, Attribute-Value Pairs, says this:

   The information model requires a standard attribute type (or possibly

   more than one) for each box in Figure 1:

   . . .

   o  User: [cek: Do we want this?  If one user uses different

      credentials at different times, do we think SACM components will

      need know that it's the same user?]

Kim Watson tells me that Account is more to the point than User or Credential. She suggests combining the two classes User and Credential into one class, Account.

Because an endpoint may have a machine account, and a user may have an account, Figure 1 would look something like this:

   +---------+ +---------+             +--------+*__________________
   |Hardware | |Software |   __________|Location|______             |
   |Component| |Component|  |         *+--------+*     |            |
   +---------+ +---------+  |                          |            |
        |1          |1      |         +----------+*____|            |
        |*          |*      |   ______|Account   |_____             |
   +---------+ +--------+   |  |     *+----------+*    |            |
   |Hardware | |Software|   |  |         +---------+   |            |
   |Instance | |Instance|   |  |         |Network  |___|            |
   +---------+ +--------+   |  |         |Session  |*               |
        |*      |*         *| *|         |- - - - -|               *|
        |       |___1+----------+1______*|Network  |_________+-------+
        |____________| Endpoint |_____   |Interface|*    1..*|Address|
                    1|          |0..1 |  +---------+         +-------+
                     +----------+     |      1|
                               |*     |       |_____+-------------+
                               |______|            *|Authorization|
                                part-of>            +-------------+

Does this sound OK?

Best,

                                             Cliff

Clifford Kahn

Principal Engineer/Technical Lead

---

From: Ira McDonald <[email-masked]>
Date: Sun, 9 Nov 2014 10:59:50 -0500

Hi Cliff,

Makes sense to me - unambiguous identity of a User is an even fuzzier
topic than unambiguous identity of an Endpoint.

Note - traffic monitors and scanners in the network infrastructure (off the
Endpoint) will generally be unable to identify the Account associated with
a given network transaction, but may have some (minimal) Endpoint
identity info and (less likely) some User identity info.  This has always
made User behavior monitoring difficult.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music / High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto: [email-masked]
Winter  579 Park Place  Saline, MI  48176  734-944-0094
Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434

On Sun, Nov 9, 2014 at 10:50 AM, Kahn, Clifford <[email-masked]>
wrote:

> Kim Watson tells me that Account is more to the point than User or
> Credential. She suggests combining the two classes User and Credential into
> one class, Account.
>
>
>
> Because an endpoint may have a machine account, and a user may have an
> account, Figure 1 would look something like this:
>
>
>
> _______________________________________________
> sacm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sacm
>
>

---

From: "Watson, Kimberly" <[email-masked]>
Date: Mon, 10 Nov 2014 13:54:25 +0000

Let me clarify slightly...what I noticed is that there was not a class for Account. In all the work I have been doing in continuous monitoring, I have noticed that while policies are about users and credentials, the actual system data collected to validate the policy implementation/enforcement is always "manifest" as some aspect of an account. For the user it is often the username, identity association, or privileges for the account. For credentials it is the authentication mechanisms invoked.

I know that we need to add in Account. I know that user and credential do not have much "meaning" independent of an account when collecting operational data. I also agree with the note from Ira, that user identification is even more fraught with ambiguity than endpoint identification.

I'm willing to keep user if we feel attributes about the user as associated with the account are in scope for endpoint assessment. I know that there were/are some USGCB checks that were "user" based, but I don't know if they really were about the user or about the account that the user used...

I'm not sure credential has as much meaning in endpoint assessment...other than the conveyer of user identity information that binds the user to the account.

--
Kim Watson
Office of Cybersecurity and Communications
Federal Network Resilience
Blackberry: (202) 494-2534

From: Kahn, Clifford [mailto:[email-masked]]
Sent: Sunday, November 09, 2014 10:51 AM
To: [email-masked]
Subject: [sacm] Combining "User" and "Credential" into "Account"

Hello all.

   . . .

Does this sound OK?

Best,

                                             Cliff

Clifford Kahn

---

From: "Adam W. Montville" <[email-masked]>
Date: Mon, 10 Nov 2014 09:06:37 -0600

I think what happens more often than not is that “user” is often synonymous with “account” (in the context of Kim’s discussion below).  We may want “user” to mean “human”, but in guidance (i.e. benchmarks, etc.) “user” can’t really mean “human” and must mean “account”.  This is why credential management recommendations are made in benchmarks - to try to ensure, to as high a degree as possible, that only one account is issued to a user (human).  Then, human and user can be used interchangeably.

If we mean “account” when we say “user”, then we should make that clear.  If we mean “human” when we say “user”, then we might want to have a scope-creep discussion, because I’m not confident unique human identification is really what we’re supporting here.

Adam

> On Nov 10, 2014, at 7:54 AM, Watson, Kimberly <[email-masked]> wrote:
> 
> Let me clarify slightly…what I noticed is that there was not a class for Account. In all the work I have been doing in continuous monitoring, I have noticed that while policies are about users and credentials, the actual system data collected to validate the policy implementation/enforcement is always “manifest” as some aspect of an account. For the user it is often the username, identity association, or privileges for the account. For credentials it is the authentication mechanisms invoked.
>  
> I know that we need to add in Account. I know that user and credential do not have much “meaning” independent of an account when collecting operational data. I also agree with the note from Ira, that user identification is even more fraught with ambiguity than endpoint identification.
>  
> I’m willing to keep user if we feel attributes about the user as associated with the account are in scope for endpoint assessment. I know that there were/are some USGCB checks that were “user” based, but I don’t know if they really were about the user or about the account that the user used…
>  
> I’m not sure credential has as much meaning in endpoint assessment...other than the conveyer of user identity information that binds the user to the account.
>  
> --
> Kim Watson

---

From: David Harrington <[email-masked]>
Date: Tue, 11 Nov 2014 11:13:59 -0500

Hi,

I think to be consistent with other IETF standards, “user” is the term of choice, where a “user” can represent a human, or an application, or even an endpoint.
Because monitoring protocols make potentially sensitive information accessible, it is important to authenticate the “user”, and to use the authentic teed user in authorization policies.

I have not seen “account” used in IETF standard monitoring protocols like snmp and netconf and radius and diameter and IETF standard security protocols like tis and ssh.
I have not worked with a system where user is "always manifest in some type of account”. 

If I am an operator for an enterprise, and I want to assess the security posture of an endpoint within the enterprise, what “account” am I manifest in?

I think of account as a layer 8 business relationship between the provider of a service and their customer.
I think of user as being the identity of a security principal at layer 3 (ipsec) or layer 4 (tis) or a layer 7 application principal (ssh, snmp, netconf, radius, diameter, etc.)
And in none of those mentioned protocols is the “account” terminology used, and considered synonymous with “user”.

In IETF security protocols, where we bind credentials and the user the credentials represent, we often have a session, but I haven’t found mention of binding a user identity to an account.

I do not think user and account are synonymous, nor do I find user to be always manifest in some type of account.

So I don’t think that we should combine user and credentials into account.

David Harrington
[email-masked]

---

From: "Watson, Kimberly" <[email-masked]>
Date: Wed, 12 Nov 2014 14:27:32 +0000

Interesting language distinctions, and as such, my terminology is suspect...this appears to be a difference in how lower layer communications and entities are expressed as opposed to how individuals interacting with the system to perform their daily activities are expressed. I live and breathe the latter while IETF seems to excel at the former.

to answer your question If I am an operator for an enterprise, and I want to assess the security posture of an endpoint within the enterprise, what "account" am I manifest in?

The process of endpoint assessment contains many different entities performing many different activities. First I have the application that collects a set of attributes based on some preconfigured collection scope at a preconfigured time. The human who defined that scope and time accessed the system using a credential and authentication mechanism. At that point, their identity was proxied on their behalf to the application that allowed them to define the scope based on privileges/roles assigned to the identity represented by the proxy mechanism. I blanketly called the proxy mechanism an account. This type of relationship/action happens a few more times to support the evaluation and reporting part of the assessment activity, but this should be enough to clarify my point.

What I'm describing here may be what you meant by: I think of account as a layer 8 business relationship between the provider of a service and their customer

There are critical security related endpoint posture attributes that represent who can access what, how access is granted, and how identity is validated. These may fall into your concept of business relationship, but I think they are a more layer 7 where the application is converted into network/system processes. Since humans can only interact with the network via an application of some type (even if that application is associated with a lower layer), I can see why user is considered person, application, or endpoint.

If we stick with "user" to mean any entity with privilege regardless of form, then we need to understand the information differences about what needs to be known about the different types of entities...but the fact is I cannot operationally collect from an endpoint any reality associated with a human. I can only collect information about credentials provided, authentication mechanisms invoked, results of the authentication process, and the proxied identity in use by the system after access is granted.

Human beings provide credentials to network/system access control processes. Those credentials are authenticated by those processes and used to create a proxy identity of the human in the system. proxied identities are created for applications and services as well, but they use a different credential authentication/access control process then those used for humans. The proxy identity is allowed to access certain resources, etc, depending on configuration of the operating system, domain management software, and/or other access control mechanisms. you could consider the proxy identity to be a type of credential as well, in which case the concept of user/credential has two levels of abstraction, but always a consistent bond prior to accessing resources.

This is one best left to the crowd to decide...
--
Kim Watson
Office of Cybersecurity and Communications
Federal Network Resilience
Blackberry: (202) 494-2534

From: David Harrington [mailto:[email-masked]]
Sent: Tuesday, November 11, 2014 11:14 AM
To: Adam W. Montville
Cc: Watson, Kimberly; [email-masked]
Subject: Re: [sacm] Combining "User" and "Credential" into "Account"

Hi,

I think to be consistent with other IETF standards, "user" is the term of choice, where a "user" can represent a human, or an application, or even an endpoint.
Because monitoring protocols make potentially sensitive information accessible, it is important to authenticate the "user", and to use the authentic teed user in authorization policies.

I have not seen "account" used in IETF standard monitoring protocols like snmp and netconf and radius and diameter and IETF standard security protocols like tis and ssh.
I have not worked with a system where user is "always manifest in some type of account".

If I am an operator for an enterprise, and I want to assess the security posture of an endpoint within the enterprise, what "account" am I manifest in?

I think of account as a layer 8 business relationship between the provider of a service and their customer.
I think of user as being the identity of a security principal at layer 3 (ipsec) or layer 4 (tis) or a layer 7 application principal (ssh, snmp, netconf, radius, diameter, etc.)
And in none of those mentioned protocols is the "account" terminology used, and considered synonymous with "user".

In IETF security protocols, where we bind credentials and the user the credentials represent, we often have a session, but I haven't found mention of binding a user identity to an account.

So I don't think that we should combine user and credentials into account.

David Harrington
[email-masked]<mailto:[email-masked]>

On Nov 10, 2014, at 10:06 AM, Adam W. Montville <[email-masked]<mailto:[email-masked]>> wrote:

I think what happens more often than not is that "user" is often synonymous with "account" (in the context of Kim's discussion below).  We may want "user" to mean "human", but in guidance (i.e. benchmarks, etc.) "user" can't really mean "human" and must mean "account".  This is why credential management recommendations are made in benchmarks - to try to ensure, to as high a degree as possible, that only one account is issued to a user (human).  Then, human and user can be used interchangeably.

If we mean "account" when we say "user", then we should make that clear.  If we mean "human" when we say "user", then we might want to have a scope-creep discussion, because I'm not confident unique human identification is really what we're supporting here.

Adam

On Nov 10, 2014, at 7:54 AM, Watson, Kimberly <[email-masked]<mailto:[email-masked]>> wrote:

From: Kahn, Clifford [mailto:[email-masked]]
Sent: Sunday, November 09, 2014 10:51 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [sacm] Combining "User" and "Credential" into "Account"

Hello all.

Does this sound OK?

Best,
                                             Cliff

Clifford Kahn

_______________________________________________
sacm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sacm

_______________________________________________
sacm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sacm