From y.oiwa@aist.go.jp  Mon Aug 13 21:09:53 2012
Return-Path: <y.oiwa@aist.go.jp>
X-Original-To: http-auth@ietfa.amsl.com
Delivered-To: http-auth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A0A521F863B for <http-auth@ietfa.amsl.com>; Mon, 13 Aug 2012 21:09:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.6
X-Spam-Level: 
X-Spam-Status: No, score=-7.6 tagged_above=-999 required=5 tests=[AWL=-1.623,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aB2-yeBkcSAi for <http-auth@ietfa.amsl.com>; Mon, 13 Aug 2012 21:09:52 -0700 (PDT)
Received: from na3sys010aog114.obsmtp.com (na3sys010aog114.obsmtp.com [74.125.245.96]) by ietfa.amsl.com (Postfix) with ESMTP id 8A12521F862A for <http-auth@ietf.org>; Mon, 13 Aug 2012 21:09:52 -0700 (PDT)
Received: from mail-gg0-f200.google.com ([209.85.161.200]) (using TLSv1) by na3sys010aob114.postini.com ([74.125.244.12]) with SMTP ID DSNKUCnPjUXjg+tzW1A0jk2e2S1COpAFgSiZ@postini.com; Mon, 13 Aug 2012 21:09:52 PDT
Received: by gglu4 with SMTP id u4so47807284ggl.11 for <http-auth@ietf.org>; Mon, 13 Aug 2012 21:09:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aist.go.jp; s=google; h=mime-version:from:date:message-id:subject:to:cc:content-type; bh=PSsXXYX1Xs0bsjiTYNegaptFTzGQyyI3dfr+BDGakdE=; b=ldPpCLqQaL2Xj+LpqHkUZHEw4EctBWukBoQkvCMeFlkZanFurPhQyUnKU7dybBqw8G AKsdLrDDo5YgbeCl27zKfm3mICs3jlj7aJ3SANCRC6U8aomLvUvaGqEIJr+3JAGTMmkY 3Qb6DvhZjobAYo4w5FoYWSWvoUY60Pjlp6GL0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type :x-gm-message-state; bh=PSsXXYX1Xs0bsjiTYNegaptFTzGQyyI3dfr+BDGakdE=; b=LDzQbU72VcfPOGvuotU+tguFNj0BBQx3mEI1///PONy5OAosPsP5qltdAFKSRjNQbE hqEMzwGcsNuxfryjVM/wKXX51AUMZbciRNXanNlzA96Yl+3wQHG4P+u2QKALILiBlB+k wf7o50LdG5i8dP1VnF1uGko9NLRBJId0BfnQTiRLGh5CMmFU0X2j81mMqPJdvuS5MexT wi50aNkvAGUIicvG/aY52nk57PrMr9XKMR5/o3z5aFR7d4ABo79iW86m71wkIfom5CGY 8pO7nJ0yRDKFwc9tdt1D9O2d/1JUpnbDmKdJz27uUdcHFh/VCjZbg+kXBMtqPUvmD53t T2wg==
Received: by 10.42.97.70 with SMTP id m6mr7487730icn.27.1344917389126; Mon, 13 Aug 2012 21:09:49 -0700 (PDT)
Received: by 10.42.97.70 with SMTP id m6mr7487723icn.27.1344917389044; Mon, 13 Aug 2012 21:09:49 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.50.99.3 with HTTP; Mon, 13 Aug 2012 21:09:28 -0700 (PDT)
From: Yutaka OIWA <y.oiwa@aist.go.jp>
Date: Tue, 14 Aug 2012 13:09:28 +0900
Message-ID: <CAMeZVws_0ETM9UmTUMZbCRxG8PO9rS21a19MYiSUC7QnJubnQA@mail.gmail.com>
To: scim Mailing List <scim@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1
X-Gm-Message-State: ALoCoQm/V8zpmgRemoLjRDecgDEWW4FVthSyBCWoYHnZ3XN6p6Kk7imIo2UllH3/SvKeu217omnziMxhjMy0lqG4cJk1EPmgE2C0l1Mjftr2GSM+DbY2hdy3ByZ+JV5IRCStjKhKUkIsxc5LURfkm5zzgUd5TlhW9g==
Cc: http-auth@ietf.org
Subject: [http-auth] scim data format and structured credentials delivery/installations
X-BeenThere: http-auth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: HTTP authentication methods <http-auth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/http-auth>, <mailto:http-auth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/http-auth>
List-Post: <mailto:http-auth@ietf.org>
List-Help: <mailto:http-auth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/http-auth>, <mailto:http-auth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Aug 2012 04:09:53 -0000

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: <y.oiwa@aist.go.jp>, <yutaka@oiwa.jp>
OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D  3139 8677 9BD2 4405 46B5]

From rifatyu@avaya.com  Fri Aug 31 06:46:16 2012
Return-Path: <rifatyu@avaya.com>
X-Original-To: http-auth@ietfa.amsl.com
Delivered-To: http-auth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E69E321F8621 for <http-auth@ietfa.amsl.com>; Fri, 31 Aug 2012 06:46:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.265
X-Spam-Level: 
X-Spam-Status: No, score=-3.265 tagged_above=-999 required=5 tests=[AWL=0.333,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jIOpLQMvxPaY for <http-auth@ietfa.amsl.com>; Fri, 31 Aug 2012 06:46:16 -0700 (PDT)
Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 284B221F85A7 for <http-auth@ietf.org>; Fri, 31 Aug 2012 06:46:15 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av4EAPm+QFDGmAcF/2dsb2JhbABFgkq4TIEHgicSG14BFWsmAQQbGodrC5p0hCOdKASRKmADm1mKGYJ/
X-IronPort-AV: E=Sophos;i="4.80,348,1344225600";  d="scan'208,217";a="364970091"
Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 31 Aug 2012 09:41:26 -0400
Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by co300216-co-erhwest-out.avaya.com with ESMTP; 31 Aug 2012 09:40:03 -0400
Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.193]) by DC-US1HCEX3.global.avaya.com ([135.11.52.22]) with mapi; Fri, 31 Aug 2012 09:46:14 -0400
From: "Shekh-Yusef, Rifaat (Rifaat)" <rifatyu@avaya.com>
To: "http-auth@ietf.org" <http-auth@ietf.org>
Date: Fri, 31 Aug 2012 09:46:12 -0400
Thread-Topic: HTTP Digest Access Authentication Algorithm Update
Thread-Index: Ac2HfvwebMPo2NGyS+KQASMR3SvoAQ==
Message-ID: <6369CB70BFD88942B9705AC1E639A338232A2BADD9@DC-US1MBEX4.global.avaya.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_6369CB70BFD88942B9705AC1E639A338232A2BADD9DCUS1MBEX4glo_"
MIME-Version: 1.0
Subject: [http-auth] HTTP Digest Access Authentication Algorithm Update
X-BeenThere: http-auth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: HTTP authentication methods <http-auth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/http-auth>, <mailto:http-auth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/http-auth>
List-Post: <mailto:http-auth@ietf.org>
List-Help: <mailto:http-auth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/http-auth>, <mailto:http-auth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 31 Aug 2012 13:46:17 -0000

--_000_6369CB70BFD88942B9705AC1E639A338232A2BADD9DCUS1MBEX4glo_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hello,



The Digest mechanism, widely used in SIP networks, is based on the HTTP Dig=
est mechanism defined in RFC 2617.

The HTTP Digest mechanism states that MD5 is the algorithm to be used, and =
while it allows other algorithms to be added (per the 'token' defined in Se=
ction 3.2.1, algorithm =3D "algorithm" "=3D" ( "MD5" | "MD5-sess" | token )=
), no other algorithm is specified.



In 2008 the US-CERT issued a note that MD5 "should be considered cryptograp=
hically broken and unsuitable for further use". The following draft is an a=
ttempt to specify extensions to the HTTP Digest Access Authentication schem=
e by adding support for the SHA1 and SHA2 suite of hash algorithms.



https://datatracker.ietf.org/doc/draft-ahrens-httpbis-digest-auth-update/?i=
nclude_text=3D1





Our initial goal was to address the issue for SIP, but when we discussed th=
is topic offline with Mark Nottingham (HTTPbis chair) and Tobias Gondrom (W=
ebSec co-chair), they suggested to us to submit it in the context of HTTPbi=
s to allow the group to consider HTTP Digest as one of the mechanisms for H=
TTP 2.0.



We would really appreciate it if people can review the draft and provide us=
 with their feedback on the following:

1. The basic idea of extending RFC2617 to support other algorithms.

2. Including the extended HTTP Digest mechanism in HTTP 2.0.



Regards,

Rifaat



--_000_6369CB70BFD88942B9705AC1E639A338232A2BADD9DCUS1MBEX4glo_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40"><head><meta http-equiv=3DContent-Type content=
=3D"text/html; charset=3Dus-ascii"><meta name=3DGenerator content=3D"Micros=
oft Word 12 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Consolas;
	panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{mso-style-priority:99;
	mso-style-link:"Plain Text Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:10.5pt;
	font-family:Consolas;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.PlainTextChar
	{mso-style-name:"Plain Text Char";
	mso-style-priority:99;
	mso-style-link:"Plain Text";
	font-family:Consolas;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]--></head><body lang=3DEN-US link=3Dblue vli=
nk=3Dpurple><div class=3DWordSection1><p class=3DMsoPlainText>Hello,<o:p></=
o:p></p><p class=3DMsoPlainText><o:p>&nbsp;</o:p></p><p class=3DMsoPlainTex=
t>The Digest mechanism, widely used in SIP networks, is based on the HTTP D=
igest mechanism defined in RFC 2617.<o:p></o:p></p><p class=3DMsoPlainText>=
The HTTP Digest mechanism states that MD5 is the algorithm to be used, and =
while it allows other algorithms to be added (per the 'token' defined in Se=
ction 3.2.1, algorithm =3D &quot;algorithm&quot; &quot;=3D&quot; ( &quot;MD=
5&quot; | &quot;MD5-sess&quot; | token )), no other algorithm is specified.=
<o:p></o:p></p><p class=3DMsoPlainText><o:p>&nbsp;</o:p></p><p class=3DMsoP=
lainText>In 2008 the US-CERT issued a note that MD5 &quot;should be conside=
red cryptographically broken and unsuitable for further use&quot;. The foll=
owing draft is an attempt to specify extensions to the HTTP Digest Access A=
uthentication scheme by adding support for the SHA1 and SHA2 suite of hash =
algorithms.<o:p></o:p></p><p class=3DMsoPlainText><o:p>&nbsp;</o:p></p><p c=
lass=3DMsoPlainText><a href=3D"https://datatracker.ietf.org/doc/draft-ahren=
s-httpbis-digest-auth-update/?include_text=3D1">https://datatracker.ietf.or=
g/doc/draft-ahrens-httpbis-digest-auth-update/?include_text=3D1</a><o:p></o=
:p></p><p class=3DMsoPlainText><o:p>&nbsp;</o:p></p><p class=3DMsoPlainText=
><o:p>&nbsp;</o:p></p><p class=3DMsoPlainText>Our initial goal was to addre=
ss the issue for SIP, but when we discussed this topic offline with Mark No=
ttingham (HTTPbis chair) and Tobias Gondrom (WebSec co-chair), they suggest=
ed to us to submit it in the context of HTTPbis to allow the group to consi=
der HTTP Digest as one of the mechanisms for HTTP 2.0.<o:p></o:p></p><p cla=
ss=3DMsoPlainText><o:p>&nbsp;</o:p></p><p class=3DMsoPlainText>We would rea=
lly appreciate it if people can review the draft and provide us with their =
feedback on the following:<o:p></o:p></p><p class=3DMsoPlainText>1. The bas=
ic idea of extending RFC2617 to support other algorithms.<o:p></o:p></p><p =
class=3DMsoPlainText>2. Including the extended HTTP Digest mechanism in HTT=
P 2.0.<o:p></o:p></p><p class=3DMsoPlainText><o:p>&nbsp;</o:p></p><p class=
=3DMsoPlainText>Regards,<o:p></o:p></p><p class=3DMsoPlainText> Rifaat<o:p>=
</o:p></p><p class=3DMsoPlainText><o:p>&nbsp;</o:p></p></div></body></html>=

--_000_6369CB70BFD88942B9705AC1E639A338232A2BADD9DCUS1MBEX4glo_--