Re: [KEYPROV] Correction Re:PROTOWRITEUPfor draft-ietf-keyprov-symmetrickeyformat-07

"Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com> Thu, 04 March 2010 11:06 UTC

Return-Path: <hannes.tschofenig@nsn.com>
X-Original-To: keyprov@core3.amsl.com
Delivered-To: keyprov@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EF2928C0D9 for <keyprov@core3.amsl.com>; Thu, 4 Mar 2010 03:06:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hJWdDYhSte7h for <keyprov@core3.amsl.com>; Thu, 4 Mar 2010 03:06:09 -0800 (PST)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 586AA3A890F for <keyprov@ietf.org>; Thu, 4 Mar 2010 03:06:07 -0800 (PST)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o24B677m023616 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 4 Mar 2010 12:06:07 +0100
Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o24B65Hn024095; Thu, 4 Mar 2010 12:06:07 +0100
Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Mar 2010 12:06:06 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 04 Mar 2010 13:05:27 +0200
Message-ID: <3D3C75174CB95F42AD6BCC56E5555B450246E3F9@FIESEXC015.nsn-intra.net>
In-Reply-To: <4B8F8FB9.4030207@telia.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [KEYPROV] Correction Re:PROTOWRITEUPfor draft-ietf-keyprov-symmetrickeyformat-07
Thread-Index: Acq7iBjEhB4IGwFpSjSsn1BTtnn6QQAABSzg
References: <5BFE9E473DBFC24CA87F18F29B3F0AC406890589@sur-corp-ex-02.corp.ad.activcard.com> <4B8E91C6.4040507@telia.com> <F4E86EE3B25D5B4686A74658EB3593E13A46D8@mou1wnexmb03.vcorp.ad.vrsn.com><4B8EB3E0.3070706@telia.com> <4B8F8FB9.4030207@telia.com>
From: "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com>
To: ext Anders Rundgren <anders.rundgren@telia.com>, "Bajaj, Siddharth" <SBajaj@verisign.com>
X-OriginalArrivalTime: 04 Mar 2010 11:06:06.0361 (UTC) FILETIME=[AFD93890:01CABB8A]
Cc: keyprov@ietf.org
Subject: Re: [KEYPROV] Correction Re:PROTOWRITEUPfor draft-ietf-keyprov-symmetrickeyformat-07
X-BeenThere: keyprov@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Provisioning of Symmetric Keys \(keyprov\)" <keyprov.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/keyprov>, <mailto:keyprov-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/keyprov>
List-Post: <mailto:keyprov@ietf.org>
List-Help: <mailto:keyprov-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/keyprov>, <mailto:keyprov-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Mar 2010 11:06:11 -0000

Hi Anders, 

You raise an interesting point on how this work (and similar activities
in the area of authentication protocols) relate to the huge body of work
on identity management, including the work that happens inside the IETF
on OAuth but also work that happens outside the IETF (and you mentioned
InfoCard). 

Many of the SSO protocols do not focus on the authentication part; they
consider this outside the scope of their work. This obviously creates
problems since two effects can be observed. Human interaction is
required as a consequence in many cases and often weak credentials are
being used.

Then, there are use case where you don't have a human involved at all
(like in some of the cases that are being discussed in the Oauth group).


Now, the question is whether these identity providers (asserting
parties) would have interest to standardize authentication mechanisms.
There have been some initial attempts to do so but I am not sure whether
they were driven by standardization people or indeed by market demand.
Such an example is the usage of the SASL authentication framework run
top of HTTP. This is, however, a bit different to some of the documents
we have been working on in this group 

Are you heading into this direction or did I completely misunderstood
your ideas, Anders? 

Given that I plan to send all our documents to the IESG by this IETF
meeting I am interested to hear where this effort will go next. 


Ciao
Hannes 

>-----Original Message-----
>From: keyprov-bounces@ietf.org 
>[mailto:keyprov-bounces@ietf.org] On Behalf Of ext Anders Rundgren
>Sent: 04 March, 2010 12:47
>To: Bajaj, Siddharth
>Cc: keyprov@ietf.org
>Subject: [KEYPROV] Correction Re:PROTOWRITEUPfor 
>draft-ietf-keyprov-symmetrickeyformat-07
>
>Just to get it straight:
>
>I think the chairs (Hannes and Phil) and the people who wrote 
>the KEYPROV I-Ds have done an *excellent* job!
>
>What I'm "dissing" is the fact that most of the vendors have 
>developed a browser-interface for the provisioning but they 
>haven't made the details of that public. This is surely not 
>the way you create ubiquitous standards but that was maybe not 
>on the menu?
>
>Going back to OATH, it seems that the HOTP algorithm is the 
>only thing that deserves being called "standard" since 
>handheld HOTP devices should actually be interchangable.
>
>Standardizing card interfaces and middleware for OTP is 
>undoable since the actual application "Programmatic OTP" is 
>quite marginal, in fact, I have to date in not seen a single 
>installation using such a scheme.
>
>Taking a 128-160 bit key and mutilating it to 30-40 bits when 
>running in a computer-to-computer authentication scenario may 
>be a way to preserve investments in validation software but as 
>a foundation for the future it seems like a fairly silly 
>solution when a standard (in all respects) HTTP Digest 
>Authentication does the same job (and is already in every 
>browser) but without adding truncation which cause difficult 
>to handle OTP sync issues and introduces susceptibility to DoS attacks.
>
>http://www.ietf.org/mail-archive/web/keyprov/current/msg00514.html
>
>But I think PKI and Information Cards is really the only way 
>to go, OTP should be confined to handhelds where it is doing a 
>very nice job.
>
>Anders
>
>Anders Rundgren wrote:
>> Siddharth,
>> 
>> You are right, a number of vendors have invested in what I consider 
>> dubious product concepts like "connected OTP".
>> 
>> I don't see why anyone would have to wait on the standard since the 
>> required middleware is 100% non-standard.
>> 
>> I.e. there is no client-side interoperability whatsoever between for 
>> example VeriSign and RSA.  It was actually never a goal, as far as I 
>> remember.
>> 
>> Sorry for being negative but from my horizon KEYPROV became a very 
>> marginal scheme which is the reason I'm pursuing entirely different 
>> paths which may indeed one day reach OATH's to date not 
>realized vision.
>> 
>> Anders
>> 
>> Bajaj, Siddharth wrote:
>>>  
>>> Hi Anders,
>>>  
>>> I'll beg to differ you with you - several OATH members including 
>>> VeriSign have implemented drafts of the online provisioning 
>protocol 
>>> in their products today.
>>>  
>>> Others are waiting for this standard to be finalized so 
>that they can 
>>> implement the final versions.
>>> Thanks,
>>>  
>>> Siddharth
>>>
>>> 
>---------------------------------------------------------------------
>>> ---
>>> *From:* keyprov-bounces@ietf.org on behalf of Anders Rundgren
>>> *Sent:* Wed 3/3/2010 8:43 AM
>>> *To:* Philip Hoyer
>>> *Cc:* keyprov@ietf.org
>>> *Subject:* Re: [KEYPROV] PROTOWRITEUPfor
>>> draft-ietf-keyprov-symmetrickeyformat-07
>>>
>>> Philip Hoyer wrote:
>>>  > And how is that redundant to an openly discussed peer reviewed 
>>> agreed  > IETF standard that RSA has also contributed to?
>>>
>>> There has indeed been open discussions regarding the *content* of 
>>> draft.  However, there has not been much open discussions regarding
>>> *utility* and *deployment*, something which I feel has hampered the 
>>> entire KEYPROV effort.
>>>
>>> Why would anybody in their right mind use on-line provisioning with 
>>> DSKPP for discrete OTP tokens?  Isn't sort of half the 
>value with OTP 
>>> *getting away* from middleware?
>>>
>>> RSA, VeriSign, Nicrosoft, IBM etc have contributed to many 
>standards 
>>> but not all of them have been successful in the marketplace.
>>>
>>> Anders
>>>
>>>  >
>>>  >
>>>  > ----- Original Message -----
>>>  > From: Anders Rundgren <anders.rundgren@telia.com>  > To: Philip 
>>> Hoyer  > Cc: turners@ieca.com <turners@ieca.com>; keyprov@ietf.org 
>>> <keyprov@ietf.org>  > Sent: Wed Mar 03 17:10:46 2010  > 
>Subject: Re: 
>>> [KEYPROV] PROTO WRITEUPfor  > 
>>> draft-ietf-keyprov-symmetrickeyformat-07
>>>  >
>>>  > Philip Hoyer wrote:
>>>  >  > Redundant to what exactly?
>>>  >
>>>  > I believe I elaborated that in my initial posting.
>>>  >
>>>  > RSA have had seeds distributed in XML format for ages and they 
>>> work  > on multiple platforms including mobile phones.
>>>  >
>>>  >
>>>  > Anders
>>>  >
>>>  >  >
>>>  >  >
>>>  >  > ----- Original Message -----
>>>  >  > From: keyprov-bounces@ietf.org 
><keyprov-bounces@ietf.org>  >  > 
>>> To: Sean Turner <turners@ieca.com>  >  > Cc: keyprov@ietf.org 
>>> <keyprov@ietf.org>  >  > Sent: Wed Mar 03 15:54:36 2010  >  > 
>>> Subject: Re: [KEYPROV] PROTO WRITEUPfor  >  > 
>>> draft-ietf-keyprov-symmetrickeyformat-07
>>>  >  >
>>>  >  > Sean Turner wrote:
>>>  >  >  > Anders,
>>>  >  >  >
>>>  >  >  > PSKC is the mandatory to implement key package and nobody, 
>>> that I am  >  >  > aware of, is trying to change that.  The 
>container 
>>> defined in  >  >  > draft-ietf-keyprov-symmetrickeyformat-07 is 
>>> optional to implement.
>>>  >  >
>>>  >  > I just said that it felt like a redundant solution.
>>>  >  >
>>>  >  > /anders
>>>  >  >
>>>  >  >
>>>  >  >  >
>>>  >  >  > spt
>>>  >  >  >
>>>  >  >  > Anders Rundgren wrote:
>>>  >  >  >> The document is great from a technical point of view.
>>>  >  >  >>
>>>  >  >  >> The utility is questionable since PSKC does the 
>same  >  >  
>>> >> thing and also interopes with DSKPP.  The rationale  >  >  >> 
>>> (which has been mentioned but not been put on paper)  >  >  
>>> "cards 
>>> cannot process XML" is true but provisioning  >  >  >> generally 
>>> relies on middleware doing the unpacking  >  >  >> and then through 
>>> some API inserting keys and attributes  >  >  >> in the card.
>>>  >  >  >>
>>>  >  >  >> Creating tokens that would decipher CMS is 
>technically  >  
>>> >  >> doable but there is absolutely no point with that  >  
>>  >>  >  
>>> >  >> In case you want to know how you can deal with XML,  >  >  >> 
>>> secure transfer of secrets, and still keep the token  >  >  
>>> device 
>>> unaware of sophisticated data structures and  >  >  >> public key 
>>> verification you may take a peek in the  >  >  >> following 
>document:
>>>  >  >  >>
>>>  >  >  >> "setPiggybackedSymmetricKey"
>>>  >  >  >>
>>>  >  >  >> http://webpki.org/papers/keygen2/sks-api-arch.pdf
>>> 
><https://connect.verisign.com/papers/keygen2/,DanaInfo=.awfdsonFvzp+s
>>> ks-api-arch.pdf>
>>>
>>>  >  >  >>
>>>  >  >  >> Anders
>>>  >  >  >> _______________________________________________
>>>  >  >  >> KEYPROV mailing list
>>>  >  >  >> KEYPROV@ietf.org
>>>  >  >  >> https://www.ietf.org/mailman/listinfo/keyprov
>>> 
><https://connect.verisign.com/mailman/listinfo/,DanaInfo=.awxyCmjzmHx
>>> 1r,SSL+keyprov>
>>>
>>>  >  >  >>
>>>  >  >  >
>>>  >  >
>>>  >  > _______________________________________________
>>>  >  > KEYPROV mailing list
>>>  >  > KEYPROV@ietf.org
>>>  >  > https://www.ietf.org/mailman/listinfo/keyprov
>>> 
><https://connect.verisign.com/mailman/listinfo/,DanaInfo=.awxyCmjzmHx
>>> 1r,SSL+keyprov>
>>>
>>>  >  >
>>>  >
>>>
>>> _______________________________________________
>>> KEYPROV mailing list
>>> KEYPROV@ietf.org
>>> https://www.ietf.org/mailman/listinfo/keyprov
>>> 
><https://connect.verisign.com/mailman/listinfo/,DanaInfo=.awxyCmjzmHx
>>> 1r,SSL+keyprov>
>>>
>>>
>> 
>> _______________________________________________
>> KEYPROV mailing list
>> KEYPROV@ietf.org
>> https://www.ietf.org/mailman/listinfo/keyprov
>> 
>
>_______________________________________________
>KEYPROV mailing list
>KEYPROV@ietf.org
>https://www.ietf.org/mailman/listinfo/keyprov
>