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

[Simon Josefsson <[e-mail]>]

Hannes Tschofenig <[e-mail]> writes:

> 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...

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

> 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?

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

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