[KEYPROV] "Authentication for the Cloud". Was: Correction

[Anders Rundgren <[e-mail]>]

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


Hannes Tschofenig wrote:
> 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: [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
>>>>
>>>
>>
>> _______________________________________________
>> KEYPROV mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/keyprov
> 
>