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

Hannes Tschofenig <Hannes.Tschofenig@gmx.net> Mon, 25 August 2008 17:17 UTC

Return-Path: <keyprov-bounces@ietf.org>
X-Original-To: keyprov-archive@optimus.ietf.org
Delivered-To: ietfarch-keyprov-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F20693A67F9; Mon, 25 Aug 2008 10:17:08 -0700 (PDT)
X-Original-To: keyprov@core3.amsl.com
Delivered-To: keyprov@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE6013A67B5 for <keyprov@core3.amsl.com>; Mon, 25 Aug 2008 10:17:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.121
X-Spam-Level:
X-Spam-Status: No, score=-2.121 tagged_above=-999 required=5 tests=[AWL=0.478, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id raa4KE4jUauP for <keyprov@core3.amsl.com>; Mon, 25 Aug 2008 10:17:06 -0700 (PDT)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id C47CE3A67E9 for <keyprov@ietf.org>; Mon, 25 Aug 2008 10:17:05 -0700 (PDT)
Received: (qmail invoked by alias); 25 Aug 2008 17:16:18 -0000
Received: from a91-154-105-144.elisa-laajakaista.fi (EHLO [192.168.255.3]) [91.154.105.144] by mail.gmx.net (mp042) with SMTP; 25 Aug 2008 19:16:18 +0200
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX1/iZuF+qcfiJg0skTRVYHZmvf91GOq5CKvm1aa38c rUrIx5rqXr8IfO
Message-ID: <48B2E8DD.5020807@gmx.net>
Date: Mon, 25 Aug 2008 20:16:13 +0300
From: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
User-Agent: Thunderbird 2.0.0.16 (Windows/20080708)
MIME-Version: 1.0
To: Simon Josefsson <simon@josefsson.org>
References: <877ia53z1u.fsf@mocca.josefsson.org>
In-Reply-To: <877ia53z1u.fsf@mocca.josefsson.org>
X-Y-GMX-Trusted: 0
X-FuHaFi: 0.49
Cc: keyprov@ietf.org
Subject: Re: [KEYPROV] YubiKey Algorithm Definition, a KeyData extension test case
X-BeenThere: keyprov@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Provisioning of Symmetric Keys \(keyprov\)" <keyprov.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/keyprov>, <mailto:keyprov-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/keyprov>
List-Post: <mailto:keyprov@ietf.org>
List-Help: <mailto:keyprov-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/keyprov>, <mailto:keyprov-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: keyprov-bounces@ietf.org
Errors-To: keyprov-bounces@ietf.org

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


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,
>       <simon@yubico.com>.
>
>    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
> KEYPROV@ietf.org
> https://www.ietf.org/mailman/listinfo/keyprov
>   

_______________________________________________
KEYPROV mailing list
KEYPROV@ietf.org
https://www.ietf.org/mailman/listinfo/keyprov