Subject: [scim] scim data format and structured credentials delivery/installations

From: Yutaka OIWA <[email-masked]>
Date: Tue, 14 Aug 2012 13:09:28 +0900

Dear SCIM people,

<background>
I am currently proposing a new HTTP authentication protocol for
enabling secure mutual authentication using shared credentials
(including pre-shared keys or passwords).
There are many features beyond conventional authentication methods,
but from the viewpoint of key/credential management (related to scim),
this authentication scheme have two properties concurrently:

 * enables use of encrypted (hashed) passwords on the server side
    - somewhat similar to Basic/Form
    - contrary to CHAP/Digest (which require passwords-equivalent),
 * allows non-plaintext exchange on-wire
    - similar to, but much stronger than CHAP/Digest
    - contrary to Basic/Form.

Server-side encrypted passwords are per-server basis,
so any stolen credential cannot be reused by other people,
provided that the client-side credentials have fair amount of entropy
(unlike 1234, password or xhtdj).
</background>

Under this background, my point asking on this mail is:
we have one missing feature on our protocol design: delivery of encrypted
passwords from clients to servers on the first registration phase.
Currently we have two ways for first-time registration:
 * letting servers know the plaintext passwords, and encrypt them on
the server side.
 * encrypting the passwords manually on the client side, while carefully
   inputing protocol-dependent security parameters that the server gives.
But both of them are unsatisfactory.
We have planned to develop a common format in the next steps
for exchanging such authentication parameters between peers
for single account registrations using Web browsers/Web Forms or other clients.

Looking beyond our proposal, there are also many key/credential formats
which requires key deliveries from clients to servers on the first
registration, including such as X.509 certificates (either full-certificate or
just DN part), unsigned RSA public keys, JWKs, SSH pubkeys,
machine-generated strong secrets, and even unix-hashed passwords.
We now aware that many parts of requirements for such use-cases are
common with what SCIM requires, and we should avoid designing two
similar parts on the same table.
I remember that in Vancouver SCIM session, some people also raised
requirements for deploying such non-plaintext secret within SCIM framework.

So, I'd like to reuse current data format for SCIM exchange for such purposes.
To do that, I plan to propose a generic extension mechanism for putting key
formats other than just plaintext passwords.   Such format may be useful for
other credentials as well,  and it can, of course, be used for SCIM-based
account management.
So I think that this extension satisfies some needs for SCIM as well as
other use cases.

Feedbacks are appreciated.

-- 
Yutaka OIWA, Ph.D.              Leader, Software Reliability Research Group
                             Research Institute for Secure Systems (RISEC)
   National Institute of Advanced Industrial Science and Technology (AIST)
                     Mail addresses: <[email-masked]>, <[email-masked]>
OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D  3139 8677 9BD2 4405 46B5]

---

From: Anthony Nadalin <[email-masked]>
Date: Tue, 14 Aug 2012 19:54:36 +0000

I just question the delivery of passwords at all, clear text or encrypted.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Yutaka OIWA
Sent: Monday, August 13, 2012 9:09 PM
To: scim Mailing List
Cc: [email-masked]
Subject: [scim] scim data format and structured credentials delivery/installations

Dear SCIM people,

<background>
I am currently proposing a new HTTP authentication protocol for enabling secure mutual authentication using shared credentials (including pre-shared keys or passwords).
There are many features beyond conventional authentication methods, but from the viewpoint of key/credential management (related to scim), this authentication scheme have two properties concurrently:

Server-side encrypted passwords are per-server basis, so any stolen credential cannot be reused by other people, provided that the client-side credentials have fair amount of entropy (unlike 1234, password or xhtdj).
</background>

Under this background, my point asking on this mail is:
we have one missing feature on our protocol design: delivery of encrypted passwords from clients to servers on the first registration phase.
Currently we have two ways for first-time registration:
 * letting servers know the plaintext passwords, and encrypt them on the server side.
 * encrypting the passwords manually on the client side, while carefully
   inputing protocol-dependent security parameters that the server gives.
But both of them are unsatisfactory.
We have planned to develop a common format in the next steps for exchanging such authentication parameters between peers for single account registrations using Web browsers/Web Forms or other clients.

Looking beyond our proposal, there are also many key/credential formats which requires key deliveries from clients to servers on the first registration, including such as X.509 certificates (either full-certificate or just DN part), unsigned RSA public keys, JWKs, SSH pubkeys, machine-generated strong secrets, and even unix-hashed passwords.
We now aware that many parts of requirements for such use-cases are common with what SCIM requires, and we should avoid designing two similar parts on the same table.
I remember that in Vancouver SCIM session, some people also raised requirements for deploying such non-plaintext secret within SCIM framework.

So, I'd like to reuse current data format for SCIM exchange for such purposes.
To do that, I plan to propose a generic extension mechanism for putting key
formats other than just plaintext passwords.   Such format may be useful for
other credentials as well,  and it can, of course, be used for SCIM-based account management.
So I think that this extension satisfies some needs for SCIM as well as other use cases.

-- 
Yutaka OIWA, Ph.D.              Leader, Software Reliability Research Group
                             Research Institute for Secure Systems (RISEC)
   National Institute of Advanced Industrial Science and Technology (AIST)
                     Mail addresses: <[email-masked]>, <[email-masked]>
OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D  3139 8677 9BD2 4405 46B5] _______________________________________________
scim mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/scim

---

From: Phil Hunt <[email-masked]>
Date: Tue, 14 Aug 2012 15:47:36 -0600

If one were moving away from an ldap directory to say a scim directory how would you set a password in the directory without using ldap?  IOW, what if the self-service api used scim?

Phil

On 2012-08-14, at 13:54, Anthony Nadalin <[email-masked]> wrote:

> _______________________________________________
> scim mailing list
> [email-masked]

---

From: Igor Faynberg <[email-masked]>
Date: Tue, 14 Aug 2012 18:35:28 -0400

Just to interject some thoughts and more questions:

I think this goes back to the question that Hui-Lan raised at the 
meeting during Kelly's presentation. As Kelly explained, there were 
different use cases, and we need to differentiate. (Also a good topic to 
relflect in the use case document!)

One use case is the first-time provisioning, on which the initial 
password  (assumed to be known to the end-user) has to be stored 
temporarily until it is changed by the end-user.  The other was the 
actual act of changing the password.

As we thought more about it, it appears that in neither case should the 
password be actually stored (only its salted hash should be stored, 
along with salt).  But if the salt is to be chosen by the database only, 
this will necessitate  the transmission of the password itself in the 
case of the first-time provisioning. The threat here can, of course, be 
mitigated by  a combination of 1) fast action by the end-user to reset 
the password and 2) multiple-factor authentication during the reset.

But can we come up with specifying a way to get an agreement on the 
value of salt before the provisioning so that the provisioning entity 
and the directory share it? If we can, then only the salted hash can be 
transmitted in place of the password. Then, during the reset, the 
directory will of course generate the new salt.  Another alternative, 
potentially subject to dictionary attack, is to transmit both the salt 
and the hashed password.

Igor

On 8/14/2012 5:47 PM, Phil Hunt wrote:
> On 2012-08-14, at 13:54, Anthony Nadalin<[email-masked]>  wrote:
>
> tf.org/mailman/listinfo/scim

---

From: Melinda Shore <[email-masked]>
Date: Tue, 14 Aug 2012 14:52:51 -0800

I suspect that the password problem is going to be unduly hairy, given
the proliferation of password schemes - in particular proprietary ones.
My first question would actually be this: is there an expectation that
the password (or at least the initial password) in the service being
provisioned from is going to be the same as the one being used in the
system being provisioned to?  Let's say, for the sake of argument,
that they're both storing hashed password - how do you know they're
both using the same hash algorithm?  What if they're not?  And what
about those cases where the company who developed the service being
provisioned to is less than clueful about security and they don't
want to tell you what they're doing with passwords?  It happens.

At the moment my feeling is that the password attribute should
probably be an opaque blob, acknowledging the non-trivial potential
for interoperability problems.  I suspect those interoperability
problems are going to be there, anyway, just given the nature of
how authentication is treated in Product Land.  I could probably
wake up tomorrow and feel completely differently, but at the moment
it's not clear to me that specifying what goes into a password
attribute is going to be much of an aid to interoperability.

Melinda

---

From: Anthony Nadalin <[email-masked]>
Date: Tue, 14 Aug 2012 23:40:23 +0000

Could be hints/parts/entrpy/rules but not the actual password

-----Original Message-----
From: Phil Hunt [mailto:[email-masked]] 
Sent: Tuesday, August 14, 2012 2:48 PM
To: Anthony Nadalin
Cc: Yutaka OIWA; scim Mailing List; [email-masked]
Subject: Re: [scim] scim data format and structured credentials delivery/installations

Phil

---

From: Michael Hammer <[email-masked]>
Date: Wed, 15 Aug 2012 04:55:09 +0000

Diffie-Helman anyone?

There are ways to generate keys without a middleman attack.
See what ZRTP does.

Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Igor
Faynberg
Sent: Tuesday, August 14, 2012 3:35 PM
To: [email-masked]
Subject: Re: [scim] scim data format and structured credentials
delivery/installations

I think this goes back to the question that Hui-Lan raised at the meeting
during Kelly's presentation. As Kelly explained, there were different use
cases, and we need to differentiate. (Also a good topic to relflect in the
use case document!)

One use case is the first-time provisioning, on which the initial password
(assumed to be known to the end-user) has to be stored temporarily until it
is changed by the end-user.  The other was the actual act of changing the
password.

As we thought more about it, it appears that in neither case should the
password be actually stored (only its salted hash should be stored, along
with salt).  But if the salt is to be chosen by the database only, this will
necessitate  the transmission of the password itself in the case of the
first-time provisioning. The threat here can, of course, be mitigated by  a
combination of 1) fast action by the end-user to reset the password and 2)
multiple-factor authentication during the reset.

But can we come up with specifying a way to get an agreement on the value of
salt before the provisioning so that the provisioning entity and the
directory share it? If we can, then only the salted hash can be transmitted
in place of the password. Then, during the reset, the directory will of
course generate the new salt.  Another alternative, potentially subject to
dictionary attack, is to transmit both the salt and the hashed password.

Igor

On 8/14/2012 5:47 PM, Phil Hunt wrote:
> If one were moving away from an ldap directory to say a scim directory how
would you set a password in the directory without using ldap?  IOW, what if
the self-service api used scim?

---

From: Melinda Shore <[email-masked]>
Date: Tue, 14 Aug 2012 21:03:26 -0800

> Diffie-Helman anyone?

No.

Let's try to be clear about which problem is being addressed here.
It is not to generate keying material to protect a session between
client and server, or server and client, or two peers, or whomever.
It is about provisioning a *user* password along  with other
account/directory information.

Melinda

---

From: Michael Hammer <[email-masked]>
Date: Wed, 15 Aug 2012 05:24:10 +0000

So, are you saying that the password is never passed in the clear?
The earlier messages seem to suggest that it was.
That is what does not seem clear at all here.

Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Melinda Shore
Sent: Tuesday, August 14, 2012 10:03 PM
To: [email-masked]
Subject: Re: [scim] scim data format and structured credentials
delivery/installations

No.

Let's try to be clear about which problem is being addressed here.
It is not to generate keying material to protect a session between client
and server, or server and client, or two peers, or whomever.
It is about provisioning a *user* password along  with other
account/directory information.

Melinda

---

From: Melinda Shore <[email-masked]>
Date: Tue, 14 Aug 2012 21:26:37 -0800

> That is what does not seem clear at all here.

You really want to do DH over a TLS connection?

Melinda

---

From: Michael Hammer <[email-masked]>
Date: Wed, 15 Aug 2012 05:33:31 +0000

I dunno, is that TLS connection proxied?

I'm just trying to follow the conversation and understand what is the
threat, if any first.
The premise has not really been stated, so we could be making different
assumptions.

Mike

-----Original Message-----
From: Melinda Shore [mailto:[email-masked]] 
Sent: Tuesday, August 14, 2012 10:27 PM
To: Michael Hammer
Cc: [email-masked]
Subject: Re: [scim] scim data format and structured credentials
delivery/installations

Melinda

---

From: Melinda Shore <[email-masked]>
Date: Tue, 14 Aug 2012 21:37:34 -0800

> The premise has not really been stated, so we could be making different

I think it has, but I could be all wet.  One of the attributes
associated with a user account is a password, and it's pretty
common to provision that into an ldap directory with an ldif
stanza.  I think the question here is about generalizing that.
Personally, I don't think it's possible because of variation
among password schemes, but clearly some other people have
something specific in mind.  I'm trying to figure out what that
is.

I would tend to assume that nobody's going to be proxying
SCIM clients or servers because of privacy concerns and the
sensitivity of the data, but you know what they say about
"assume."

Melinda

---

From: Michael Hammer <[email-masked]>
Date: Wed, 15 Aug 2012 05:45:14 +0000

Agree with you there.  I try not to assume too much.
Guess, I'll sit back and see what the use case is here.

Mike

-----Original Message-----
From: Melinda Shore [mailto:[email-masked]] 
Sent: Tuesday, August 14, 2012 10:38 PM
To: Michael Hammer
Cc: [email-masked]
Subject: Re: [scim] scim data format and structured credentials
delivery/installations

On 8/14/12 9:33 PM, Michael Hammer wrote:
> The premise has not really been stated, so we could be making 
> different assumptions.

I think it has, but I could be all wet.  One of the attributes associated
with a user account is a password, and it's pretty common to provision that
into an ldap directory with an ldif stanza.  I think the question here is
about generalizing that.
Personally, I don't think it's possible because of variation among password
schemes, but clearly some other people have something specific in mind.  I'm
trying to figure out what that is.

I would tend to assume that nobody's going to be proxying SCIM clients or
servers because of privacy concerns and the sensitivity of the data, but you
know what they say about "assume."

Melinda

---

From: Erik Wahlström <[email-masked]>
Date: Wed, 15 Aug 2012 17:36:30 +0000

This is a deep end of the pool kind of question. The use case of moving passwords is a valid one but tricky to standardize due to the fact that it's so different every where and the data is so sensitive. That's is also why it's just an opaque value in SCIM 1.1. You can just send an clear text or an agreed on format, SCIM protocol don't care at the moment. We started this same discussion but opted into just making it opaque in first version due to the complexity of it.

I think at least this should be in a future use case document for SCIM. Great if you guys have started working on this, I would love to see that extension (or core change if its solid).

/ Erik