Subject: Re: [KEYPROV] PROTO WRITEUPfor draft-ietf-keyprov-symmetrickeyformat-07

From: "Philip Hoyer" <[email-masked]>
Date: Wed, 3 Mar 2010 17:29:14 +0100

And how is that redundant to an openly discussed peer reviewed agreed IETF standard that RSA has also contributed to?

----- Original Message -----
From: Anders Rundgren <[email-masked]>
To: Philip Hoyer
Cc: [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
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: [email-masked] <[email-masked]>
> To: Sean Turner <[email-masked]>
> Cc: [email-masked] <[email-masked]>
> 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
>  >>
>  >> Anders
>  >> _______________________________________________
>  >> KEYPROV mailing list
>  >> [email-masked]
>  >> https://www.ietf.org/mailman/listinfo/keyprov
>  >>
>  >
> 
> _______________________________________________
> KEYPROV mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyprov
>

---

From: Anders Rundgren <[email-masked]>
Date: Wed, 03 Mar 2010 17:43:50 +0100

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

---

From: "Bajaj, Siddharth" <[email-masked]>
Date: Wed, 3 Mar 2010 10:21:31 -0800

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: [email-masked] on behalf of Anders Rundgren
Sent: Wed 3/3/2010 8:43 AM
To: Philip Hoyer
Cc: [email-masked]
Subject: Re: [KEYPROV] PROTOWRITEUPfor draft-ietf-keyprov-symmetrickeyformat-07

Anders

>  >  >> http://webpki.org/papers/keygen2/sks-api-arch.pdf <https://connect.verisign.com/papers/keygen2/,DanaInfo=.awfdsonFvzp+sks-api-arch.pdf> 
>  >  >>
>  >  >> Anders
>  >  >> https://www.ietf.org/mailman/listinfo/keyprov <https://connect.verisign.com/mailman/listinfo/,DanaInfo=.awxyCmjzmHx1r,SSL+keyprov> 
>  >  >>
>  >  >
>  >
>  > https://www.ietf.org/mailman/listinfo/keyprov <https://connect.verisign.com/mailman/listinfo/,DanaInfo=.awxyCmjzmHx1r,SSL+keyprov> 
>  >
>

_______________________________________________
KEYPROV mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/keyprov <https://connect.verisign.com/mailman/listinfo/,DanaInfo=.awxyCmjzmHx1r,SSL+keyprov>

---

From: Anders Rundgren <[email-masked]>
Date: Wed, 03 Mar 2010 20:09:20 +0100

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.
>  
> ------------------------------------------------------------------------
> *From:* [email-masked] on behalf of Anders Rundgren
> *Sent:* Wed 3/3/2010 8:43 AM
> *To:* Philip Hoyer
> *Cc:* [email-masked]
> *Subject:* Re: [KEYPROV] PROTOWRITEUPfor 
> <https://connect.verisign.com/papers/keygen2/,DanaInfo=.awfdsonFvzp+sks-api-arch.pdf>
>  >  >  >>
>  >  >  >> Anders
> <https://connect.verisign.com/mailman/listinfo/,DanaInfo=.awxyCmjzmHx1r,SSL+keyprov>
>  >  >  >>
>  >  >  >
>  >  >
> <https://connect.verisign.com/mailman/listinfo/,DanaInfo=.awxyCmjzmHx1r,SSL+keyprov>
>  >  >
>  >
> 
> <https://connect.verisign.com/mailman/listinfo/,DanaInfo=.awxyCmjzmHx1r,SSL+keyprov>
>

---

From: Anders Rundgren <[email-masked]>
Date: Thu, 04 Mar 2010 11:47:21 +0100

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:
>> VeriSign have implemented drafts of the online provisioning protocol 
>> in their products today.
>>

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Thu, 4 Mar 2010 13:05:27 +0200

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: [email-masked] 
>[mailto:[email-masked]] On Behalf Of ext Anders Rundgren
>Sent: 04 March, 2010 12:47
>To: Bajaj, Siddharth
>Cc: [email-masked]
>Subject: [KEYPROV] Correction Re:PROTOWRITEUPfor 
>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.
>
>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,
>> 
>> 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,
>>>  
>>> Others are waiting for this standard to be finalized so 
>that they can 
>>> implement the final versions.
>>> Thanks,
>>>  
>>> Siddharth
>>>
>>> 
>>>  > And how is that redundant to an openly discussed peer reviewed 
>>> agreed  > IETF standard that RSA has also contributed to?
>>>
>>> RSA, VeriSign, Nicrosoft, IBM etc have contributed to many 
>standards 
>>> but not all of them have been successful in the marketplace.
>>>
>>> Anders
>>>
>>>  >
>>>  >
>>>  > From: Anders Rundgren <[email-masked]>  > To: Philip 
>>> Hoyer  > Cc: [email-masked] <[email-masked]>; [email-masked] 
>>> <[email-masked]>  > Sent: Wed Mar 03 17:10:46 2010  > 
>Subject: Re: 
>>> [KEYPROV] PROTO WRITEUPfor  > 
>>>  > RSA have had seeds distributed in XML format for ages and they 
>>> work  > on multiple platforms including mobile phones.
>>>  >
>>>  >
>>>  > Anders
>>>  >
>>>  >  >
>>>  >  >
>>>  >  > From: [email-masked] 
><[email-masked]>  >  > 
>>> To: Sean Turner <[email-masked]>  >  > Cc: [email-masked] 
>>> <[email-masked]>  >  > Sent: Wed Mar 03 15:54:36 2010  >  > 
>>> Subject: Re: [KEYPROV] PROTO WRITEUPfor  >  > 
>>>  >  >  > 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.
>>>  >  >
>>>  >  >  >> 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:
>>>  >  >  >>

---

From: Anders Rundgren <[email-masked]>
Date: Thu, 04 Mar 2010 12:44:57 +0100

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

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 06 Mar 2010 10:45:37 +0200

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:
>>> From: [email-masked] [mailto:[email-masked]] On 
>>> Behalf Of ext Anders Rundgren
>>> I think the chairs (Hannes and Phil) and the people who wrote the 
>>> KEYPROV I-Ds have done an *excellent* job!
>>>
>>> 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.
>>>
>>> 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.
>>>
>>> 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,
>>>>
>>>> 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.
>>>>
>>>>> *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
>>>>>  >  >  > PSKC is the mandatory to implement key package and 
>>>>> nobody, that I am  >  >  > aware of, is trying to change that.  The 
>>> container
>>>>> (which has been mentioned but not been put on paper)  >  >  "cards 
>>>>> relies on middleware doing the unpacking  >  >  >> and then 
>>>>> through some API inserting keys and attributes  >  >  >> in the card.
>>>>>  >  >  >>
>>>>> secure transfer of secrets, and still keep the token  >  >  device

---

From: Anders Rundgren <[email-masked]>
Date: Sat, 06 Mar 2010 11:23:45 +0100

Hi Hannes,
Putting a "vision" in an I-D is beyond my capability so I can only reiterate the
things that IMO currently are missing for creating a token scheme for the "Cloud":

- Browser interface for Issuing, Managing, and Using tokens

- Supporting PKI, OTP, Information Cards etc.

- Security mechanisms that makes on-line personalization of tokens technically
   as secure as traditional smart card production in a "bunker"

- A unified system for enhanced smart cards and mobile phones with embedded
   security hardware

This is a little bit like what OATH promised some five years ago, but where
most people have put their faith into "frameworks" and "abstractions" [*],
I have gone in the opposite direction and propose "bit-level compatibility".

In practical terms it means that the required middleware would eventually be
a part of the computing platform and not be supplied by ISVs.  You may also
be able to buy a security-wise low-end (but fully compatible), token at
Wal-Mart since the scheme can be added to USB memory sticks with relative ease.

Compared to KEYPROV, SKS/KeyGen2 is roughly twice the size but that's a minor
problem since the interoperability matrix is actually MUCH smaller; the "only"
real issue is how to get platform vendor buy-in.

There are many hurdles.  I just learned that I will not be able to make an
*open* reference design using state-of-the-art crypto hardware like Atmel's
AT91SC192192CT-USB or Maxim's MAXQ1850 since these require NDAs and export
licenses so I have to stick to standard MCU technology.  OTOH, forward-looking
token vendors can build the "real stuff" based on the reference which is the
long-term goal anyway; I don't aspire to become a token manufacturer :-)

Regards
Anders

*] The German/ISO/BSI/EIC standard 24727 is an example of this