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

[Anders Rundgren <[e-mail]>]

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+sks-api-arch.pdf> 
>>
>>  >  >  >>
>>  >  >  >> Anders
>>  >  >  >> _______________________________________________
>>  >  >  >> KEYPROV mailing list
>>  >  >  >> [e-mail]
>>  >  >  >> https://www.ietf.org/mailman/listinfo/keyprov 
>> <https://connect.verisign.com/mailman/listinfo/,DanaInfo=.awxyCmjzmHx1r,SSL+keyprov> 
>>
>>  >  >  >>
>>  >  >  >
>>  >  >
>>  >  > _______________________________________________
>>  >  > KEYPROV mailing list
>>  >  > [e-mail]
>>  >  > https://www.ietf.org/mailman/listinfo/keyprov 
>> <https://connect.verisign.com/mailman/listinfo/,DanaInfo=.awxyCmjzmHx1r,SSL+keyprov> 
>>
>>  >  >
>>  >
>>
>> _______________________________________________
>> KEYPROV mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/keyprov 
>> <https://connect.verisign.com/mailman/listinfo/,DanaInfo=.awxyCmjzmHx1r,SSL+keyprov> 
>>
>>
> 
> _______________________________________________
> KEYPROV mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/keyprov
>