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

[Anders Rundgren <[e-mail]>]

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: [e-mail] 
>> [mailto:[e-mail]] On Behalf Of ext Anders Rundgren
>> Sent: 04 March, 2010 12:47
>> To: Bajaj, Siddharth
>> Cc: [e-mail]
>> 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:* [e-mail] on behalf of Anders Rundgren
>>>> *Sent:* Wed 3/3/2010 8:43 AM
>>>> *To:* Philip Hoyer
>>>> *Cc:* [e-mail]
>>>> *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 <[e-mail]>  > To: Philip 
>>>> Hoyer  > Cc: [e-mail] <[e-mail]>; [e-mail] 
>>>> <[e-mail]>  > 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: [e-mail] 
>> <[e-mail]>  >  > 
>>>> To: Sean Turner <[e-mail]>  >  > Cc: [e-mail] 
>>>> <[e-mail]>  >  > 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
>>>>  >  >  >> [e-mail]
>>>>  >  >  >> https://www.ietf.org/mailman/listinfo/keyprov
>>>>
>> <https://connect.verisign.com/mailman/listinfo/,DanaInfo=.awxyCmjzmHx
>>>> 1r,SSL+keyprov>
>>>>
>>>>  >  >  >>
>>>>  >  >  >
>>>>  >  >
>>>>  >  > _______________________________________________
>>>>  >  > KEYPROV mailing list
>>>>  >  > [e-mail]
>>>>  >  > https://www.ietf.org/mailman/listinfo/keyprov
>>>>
>> <https://connect.verisign.com/mailman/listinfo/,DanaInfo=.awxyCmjzmHx
>>>> 1r,SSL+keyprov>
>>>>
>>>>  >  >
>>>>  >
>>>>
>>>> _______________________________________________
>>>> KEYPROV mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/keyprov
>>>>
>> <https://connect.verisign.com/mailman/listinfo/,DanaInfo=.awxyCmjzmHx
>>>> 1r,SSL+keyprov>
>>>>
>>>>
>>> _______________________________________________
>>> KEYPROV mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/keyprov
>>>
>> _______________________________________________
>> KEYPROV mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/keyprov
>>
>