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

Hannes Tschofenig <Hannes.Tschofenig@gmx.net> Sat, 06 March 2010 08:46 UTC

Return-Path: <Hannes.Tschofenig@gmx.net>
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 888F33A909C for <keyprov@core3.amsl.com>; Sat, 6 Mar 2010 00:46:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.532
X-Spam-Level:
X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067, 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 douEQTTSfMzY for <keyprov@core3.amsl.com>; Sat, 6 Mar 2010 00:46:12 -0800 (PST)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 3EDE73A909A for <keyprov@ietf.org>; Sat, 6 Mar 2010 00:46:12 -0800 (PST)
Received: (qmail invoked by alias); 06 Mar 2010 08:46:14 -0000
Received: from a88-115-222-204.elisa-laajakaista.fi (EHLO [192.168.255.4]) [88.115.222.204] by mail.gmx.net (mp005) with SMTP; 06 Mar 2010 09:46:14 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX1+ziVpIrRqzRdIuScSZUK+BhE/8oe/3fx/iEd6j4f JyJiVoPS3+n65l
Message-ID: <4B921631.50409@gmx.net>
Date: Sat, 06 Mar 2010 10:45:37 +0200
From: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Anders Rundgren <anders.rundgren@telia.com>
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> <3D3C75174CB95F42AD6BCC56E5555B450246E3F9@FIESEXC015.nsn-intra.net> <4B8F9D39.5070902@telia.com>
In-Reply-To: <4B8F9D39.5070902@telia.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
X-FuHaFi: 0.46999999999999997
Cc: keyprov@ietf.org, "Bajaj, Siddharth" <SBajaj@verisign.com>, "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com>
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: Sat, 06 Mar 2010 08:46:14 -0000

Hi Anders,

in order for me to understand your proposal better it would be great if 
you could write a tiny IETF draft that outlines the architectural idea. 
I don't you think that more than 3 pages are necessary to capture the 
idea. I  am sure you could copy text from elsewhere already since you 
have written a punch of documents already (some pointers you have sent 
to this list).

We could then try to figure out whether we are on the same page.

Ciao
Hannes

Anders Rundgren wrote:
> Hi Hannes,
>
> My interest in this space is "simply" establishing some kind of
> "KEYPROV" supporting multiple authentication mechanisms (OTP, PKI
> and Information Cards), a defined middleware, and having a browser
> interface.
>
> I think that most things going on elsewhere is more like "political
> movements" (OAuth, Kantara); my project is about *shipping* stuff and
> then *after* some initial success let *other* people toil with 
> standardization.
> In addition all code will be available for anyone which serve as 
> references.
>
> Cheers,
> Anders
>
> Tschofenig, Hannes (NSN - FI/Espoo) wrote:
>> 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
>>>
>>
>
> _______________________________________________
> KEYPROV mailing list
> KEYPROV@ietf.org
> https://www.ietf.org/mailman/listinfo/keyprov