Re: [babel] hmac info model elements

"STARK, BARBARA H" <bs7652@att.com> Mon, 07 January 2019 22:18 UTC

Return-Path: <bs7652@att.com>
X-Original-To: babel@ietfa.amsl.com
Delivered-To: babel@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 900B512DDA3 for <babel@ietfa.amsl.com>; Mon, 7 Jan 2019 14:18:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nTrtjqSKyFIn for <babel@ietfa.amsl.com>; Mon, 7 Jan 2019 14:18:16 -0800 (PST)
Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2CBD129508 for <babel@ietf.org>; Mon, 7 Jan 2019 14:18:16 -0800 (PST)
Received: from pps.filterd (m0049297.ppops.net [127.0.0.1]) by m0049297.ppops.net-00191d01. (8.16.0.22/8.16.0.22) with SMTP id x07MF8ZZ018080; Mon, 7 Jan 2019 17:18:15 -0500
Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049297.ppops.net-00191d01. with ESMTP id 2pveyq8t6s-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 07 Jan 2019 17:18:15 -0500
Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x07MIDZY028444; Mon, 7 Jan 2019 17:18:14 -0500
Received: from zlp30485.vci.att.com (zlp30485.vci.att.com [135.47.91.178]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x07MIBnV028429; Mon, 7 Jan 2019 17:18:11 -0500
Received: from zlp30485.vci.att.com (zlp30485.vci.att.com [127.0.0.1]) by zlp30485.vci.att.com (Service) with ESMTP id 7FF934048C29; Mon, 7 Jan 2019 22:18:11 +0000 (GMT)
Received: from GAALPA1MSGHUBAA.ITServices.sbc.com (unknown [130.8.218.150]) by zlp30485.vci.att.com (Service) with ESMTPS id 6D1184048C1E; Mon, 7 Jan 2019 22:18:11 +0000 (GMT)
Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.5]) by GAALPA1MSGHUBAA.ITServices.sbc.com ([130.8.218.150]) with mapi id 14.03.0415.000; Mon, 7 Jan 2019 17:18:10 -0500
From: "STARK, BARBARA H" <bs7652@att.com>
To: 'Toke Høiland-Jørgensen' <toke@toke.dk>, Dave Taht <dave.taht@gmail.com>
CC: Juliusz Chroboczek <jch@irif.fr>, Mahesh Jethanandani <mjethanandani@gmail.com>, Babel at IETF <babel@ietf.org>
Thread-Topic: [babel] hmac info model elements
Thread-Index: AdSi6E9jJwLKz5kXQlCy2NNONpdJZQA7HaOAAB1GhjAAFlCHAAB9AEdgAA5ybwAAARIuAAAEYQSAAATVnJA=
Date: Mon, 07 Jan 2019 22:18:09 +0000
Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DF86FD0@GAALPA1MSGUSRBF.ITServices.sbc.com>
References: <2D09D61DDFA73D4C884805CC7865E6114DF7EECB@GAALPA1MSGUSRBF.ITServices.sbc.com> <91CABBA9-DFC0-48C5-9A36-E2B12FC376D9@gmail.com> <2D09D61DDFA73D4C884805CC7865E6114DF8354B@GAALPA1MSGUSRBF.ITServices.sbc.com> <87tvio2i9l.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114DF8669E@GAALPA1MSGUSRBF.ITServices.sbc.com> <87k1jgwhlz.fsf@toke.dk> <CAA93jw6QR4_035Q7c44hg+gQaG-9riBj5uDbo=0ahxXBwVFG6g@mail.gmail.com> <87ef9owadw.fsf@toke.dk>
In-Reply-To: <87ef9owadw.fsf@toke.dk>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.70.202.237]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-01-07_09:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1901070182
Archived-At: <https://mailarchive.ietf.org/arch/msg/babel/6ehC_kto4ZOvV-uss1OlEyniwlE>
Subject: Re: [babel] hmac info model elements
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "A list for discussion of the Babel Routing Protocol." <babel.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/babel>, <mailto:babel-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/babel/>
List-Post: <mailto:babel@ietf.org>
List-Help: <mailto:babel-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/babel>, <mailto:babel-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Jan 2019 22:18:18 -0000

> >> > Toke said: "Bird uses an unencoded string..."
> >> > <bhs> I'm not sure what "unencoded" means here? But this sounds
> >> > like maybe the entered string is a "passphrase" / PSK, like what's
> >> > used for Wi-Fi, which is then used to derive the HMAC key using
> >> > Unicode encoding?
> >>
> >> Nope, no derivation, just the raw ASCII bytes from the string used as
> >> an HMAC key, zero-padded to the block size. Unless the supplied ASCII
> >> string is longer than the block size, in which case it is hashed
> >> first.
> >
> > ^^^^^^ ???? So you are saying an overlong key is transmuted into
> > something else entirely, not truncated?
> 
> Yup, that would appear to be the case:
> 
> https://gitlab.labs.nic.cz/labs/bird/blob/master/lib/mac.c#L105

I noticed the referenced code mentioned it could be used for OSPF (RFC 5709). So I went to see if RFC 5709 had anything to say about this. And it does:
   (1) PREPARATION OF KEY
       In this application, Ko is always L octets long.

       If the Authentication Key (K) is L octets long, then Ko is equal
       to K.  If the Authentication Key (K) is more than L octets long,
       then Ko is set to H(K).  If the Authentication Key (K) is less
       than L octets long, then Ko is set to the Authentication Key (K)
       with zeros appended to the end of the Authentication Key (K),
       such that Ko is L octets long.

I'd be fine with this scheme, but think we should probably specify it somewhere, like OSPF does. 
I notice OSPF makes no mention of arriving at the Authentication Key from a string (or hex). It just assumes its dealing with something that has a length measured in octets. 
WPA2 limits its passphrase strings to "printable ASCII" characters (32 - 126). Since OSPF doesn't seem to care how it comes by the Key octets, it has no such limit in its spec. I wonder if there are any characters that would make one of the babel implementations choke; if so we may want to limit what characters can be used if input as ASCII. WPA2 does also allow hex PSK, which has no limitation on usable values.
Barbara