Subject: [KEYPROV] YubiKey Algorithm Definition, a KeyData extension test case

From: Simon Josefsson <[email-masked]>
Date: Mon, 25 Aug 2008 17:16:29 +0200

Hi All,

Inspired by Hannes posts with example definitions, I wanted to write up
an example for the YubiKey (see <http://www.yubico.com/>).  Section
5.4.1 of draft-ietf-keyprov-portable-symmetric-key-container-05 suggests
the format is extensible, but I didn't find any examples.

Some background: The KeyData for a YubiKey would need to hold the key
identity as well, since the identity is printed as part of the OTP.  The
OTP is a modhex-encoded variable length field holding the identity
string, followed by one AES-encrypted block.  The identity string is set
when the AES key is set.  Thus, I'm guessing it makes sense to store the
identity string in the KeyData structure as well, since it is important
during key configuration.  Does that sounds about right?

Section 5.4.1 contains:

<xs:complexType name="KeyDataType">
     <xs:sequence>
...
       <xs:any namespace="##other" minOccurs="0"
       maxOccurs="unbounded"/>
     </xs:sequence>
...
   o  <xs:any ..> the extension point for carrying future elements.
      Please note that all elements added MUST carry PlainValue and
      EncryptedValue sub eleemnts as described above.

I have come up with an straw man below.  However, there are two
questions:

1) How to express, in the ResponseFormat the Length field, that the
length of the OTPs can vary?  The length is from 32 characters (no
identity, just AES output) and up (when an identity string is included
as the prefix).

2) How to express the extension field with the identity?  My XML fu is
not strong enough to feel confident about the proposal below.  I think
it can be useful to include an example of when the extension mechanism
is used, so that people can understand and implement it interoperable.

I've marked these two questions with XXX below.

Thanks,
Simon

8.4.4.12.  YubiKey-EVENT

   Common Name:  YubiKey-EVENT

   Class:  OTP

   URI:  http://www.yubico.com/2008/04/algorithms/
      algorithms#ActivIdentity-EVENT

   Algorithm Definition:  http://www.yubico.com/2008/04/
      algorithms/algorithms#ActivIdentity-EVENT

   Identifier Definition  http://www.yubico.com/2008/04/
      algorithms/algorithms#ActivIdentity-EVENT

   Registrant Contact:  Simon Josefsson, Yubico,
      <[email-masked]>.

   Profile of XML attributes and subelements of the Key entity:

      For a Key of this algorithm, the <Usage> subelements MUST be
      present.  The "OTP" attribute of the <Usage> MUST be set "true"
      and it MUST be the only attribute set.  The element
      <ResponseFormat> of the <Usage> MUST be used to indicate the OTP
      length and the value format.

      For the Data elements of a key of this algorithm, the following
      subelements MUST be present in either the Key element itself or an
      commonly shared KeyProperties element.

      *  Secret

      * A YubiKeyIdentity extension field from the
         http://www.yubico.com.org/2008/08/yubikey XML namespace.  It
         has a HEXADECIMAL PlainValue field.

      An example of the Key of this algorithm is as follows.

   <?xml version="1.0" encoding="UTF-8"?>
   <KeyContainer Version="1.0"
                 xmlns="urn:ietf:params:xml:ns:keyprov:pskc:1.0"
                 xmlns:yubico="http://www.yubico.com.org/2008/08/yubikey">
       <Device>
           <DeviceInfo>
               <Manufacturer>Yubico</Manufacturer>
               <SerialNo>123456789</SerialNo>
           </DeviceInfo>
           <Key KeyAlgorithm="http://www.yubico.com/2008/04/
                algorithms/algorithms#ActivIdentity-EVENT"
                KeyId="3456789">
               <Issuer>Issuer</Issuer>
               <Usage OTP="true">
                   <ResponseFormat Length="XXX"
                   Format="ALPHANUMERIC"/>
               </Usage>
               <Data>
                   <Secret>
                       <PlainValue>
                       abZIHIurorYOjyIXm1jNVg==
                       </PlainValue>
                   </Secret>
                   <yubico:YubiKeyIdentity XXX>
                       <PlainValue>
                       2d344e83
                       </PlainValue>
                   </yubico:YubiKeyIdentity>
               </Data>
           </Key>
       </Device>
   </KeyContainer>
_______________________________________________
KEYPROV mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/keyprov

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 25 Aug 2008 20:16:13 +0300

Hi Simon,

you are right that the document does not provide enough description to 
make it easy for protocol designers to extend it.There is clearly room 
for improvement and we are working on it. Currently, there is also no 
description about the registry for these algorithm definitions since one 
should give a few guidelines on what standardized mechanisms have to 
provide. In fact I have this action item...

You example is good. I am not 100% sure that the <Data> element is the 
right place to add the identity; I need to double-check that. I took a 
look at the webpage and I got the impression that the identity is 
actually an OpenID URL. Am I wrong?

Ciao
Hannes

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 26 Aug 2008 11:25:07 +0200

> provide. In fact I have this action item...

Hi Hannes!  I am looking forward to your improved text in this area.

Do you think including the YubiKey Algorithm Definition would be useful?

Extensibility schemes are often under-specified in new protocols,
causing interop problems later on when people want to extend the
protocol.  Including an example that uses the extension mechanism in the
right way in the initial document may help to avoid that.

I'll be happy to work on improving the definition

> actually an OpenID URL. Am I wrong?

Yes.  The identity part of the OTP is typically a short string such as
'dteffuje' or 'ekhgjhbctrgn'.  It is the same in every OTP.  The OpenID
URL is normally entered by the user.

Thanks,
Simon

>>       <[email-masked]>.
>>
>> [email-masked]