From nico@cryptonector.com Fri May 3 12:39:46 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C165121F8F6E; Fri, 3 May 2013 12:39:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SvmR-TYkb4lP; Fri, 3 May 2013 12:39:41 -0700 (PDT) Received: from homiemail-a72.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id E18C621F8EFE; Fri, 3 May 2013 12:39:38 -0700 (PDT) Received: from homiemail-a72.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTP id 9302C6B007B; Fri, 3 May 2013 12:39:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:content-type; s=cryptonector.com; bh=CZbB372Z7bx1VhQyyC8nOms Z18o=; b=ypa91zxSuHFqkoz+gLGp9voUv4Gn0zNaLCqsinA/6ADmdL4LUqToZ4z 99VIbFRCPglRrFc9/llHGPGX52f//UL0GG5EXk2EeVLJoHeEWDbENc6L2dN5iT8S qE/oaLKZvGOVxSPrde6wHjre0Y9cp5uUPj6Sxpu1ixCDhA3q3J7M= Received: from mail-we0-f171.google.com (mail-we0-f171.google.com [74.125.82.171]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTPSA id 1B9016B0078; Fri, 3 May 2013 12:39:37 -0700 (PDT) Received: by mail-we0-f171.google.com with SMTP id u7so1622600wey.16 for ; Fri, 03 May 2013 12:39:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=6rwatdJU0ruAROM83vk93zbQAbCf/XZ5fXPfw1iRlvo=; b=blcpndlN/bQ330CDFecmKhwvL5+xrVzxLWEPAupzLhJTaZbmfuOy3UrX3EqfH6fkZG 9G/sQud528xWWgmptALJRWi5ZthjItEODsXWF8mf1yVWw1qBmwqm8u/y2Djv43VMWTms fAckQcZlV5YIfkA3nBgqRnB0RxKxHUgxu6Dl499uE6SU52wp/dZc4tkXqepb0UZjHjZp mTrgRHQ8oz//MZuEmNOo2DC0bCtrMPcSW25vCPLtfzauew3ndJoE6+uHoWMC7XQeol16 7Bd/POUTcxWU35c+EDENmee9QZgbrIa6cyZTl36v3nkjA16X0uCp9dwjUUb+TvhEvQO7 STxg== MIME-Version: 1.0 X-Received: by 10.194.173.167 with SMTP id bl7mr15772026wjc.50.1367609976683; Fri, 03 May 2013 12:39:36 -0700 (PDT) Received: by 10.216.111.132 with HTTP; Fri, 3 May 2013 12:39:36 -0700 (PDT) In-Reply-To: References: <20130328033951.21028.2480.idtracker@ietfa.amsl.com> <515E4D5B.5050102@stpeter.im> <51648B46.2020905@stpeter.im> Date: Fri, 3 May 2013 14:39:36 -0500 Message-ID: From: Nico Williams To: Peter Saint-Andre , precis@ietf.org, kitten@ietf.org, Alexey Melnikov Content-Type: text/plain; charset=UTF-8 Subject: Re: [kitten] Fwd: I-D Action: draft-ietf-precis-saslprepbis-01.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 19:39:46 -0000 Please forgive my apparent apathy. I lost track of this due to business travel. I'm not sure where the case mapping requirement for usernames came from. I guess it has something to do with the Turkish I and such. I can't say I'm excited about this case mapping requirement; if anything it strikes as silly. Why would we apply mappings to usernames (which are sent on the wire) that we don't apply to passwords (which servers generally don't get the plaintext of)? We need mappings for passwords to make password entry reliable. The same does NOT apply to usernames. Also, looking at SASLprep and PRECIS, I see no mention of query strings vs. display vs. storage. These distinctions matter. But maybe I'm just failing to search for the right terms. Heck, we're not even told whether these rules should be applied by the client, the server, or both. Anyways, I'm for applying as few transformations as possible to usernames on the *client* side and leaving the server to apply RECOMMENDED, and a few REQUIRED rules for matching. I don't see room for case folding in general, but I do for specific cases (e.g., Turkish I handling). If this review is too late to make a difference, well, c'est la vie. But do give the above some thought before rejecting my comments for being late. Once more, I'm sorry I let this slip. Nico -- From shawn.emery@oracle.com Fri May 3 23:02:22 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD96721F8FA7 for ; Fri, 3 May 2013 23:02:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.599 X-Spam-Level: X-Spam-Status: No, score=-7.599 tagged_above=-999 required=5 tests=[AWL=-1.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2RDBv6NuVWW9 for ; Fri, 3 May 2013 23:02:17 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 692E521F8FB8 for ; Fri, 3 May 2013 23:02:17 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r4462Fxu031238 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 4 May 2013 06:02:16 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4462FOJ016548 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Sat, 4 May 2013 06:02:15 GMT Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4462EiP016536 for ; Sat, 4 May 2013 06:02:14 GMT Received: from [10.159.100.156] (/10.159.100.156) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 03 May 2013 23:02:14 -0700 Message-ID: <5184A440.8070708@oracle.com> Date: Sat, 04 May 2013 00:01:36 -0600 From: Shawn Emery User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "kitten@ietf.org" References: <1107916100.20156.1367510389428.JavaMail.nobody@jva2tc007.webex.com> In-Reply-To: <1107916100.20156.1367510389428.JavaMail.nobody@jva2tc007.webex.com> X-Forwarded-Message-Id: <1107916100.20156.1367510389428.JavaMail.nobody@jva2tc007.webex.com> Content-Type: multipart/alternative; boundary="------------060305040005040003090209" X-Source-IP: acsinet22.oracle.com [141.146.126.238] Subject: [kitten] kitten WG Interim Meeting Information X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 May 2013 06:02:23 -0000 This is a multi-part message in MIME format. --------------060305040005040003090209 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Topic: KITTEN WG Interim Date: Monday, May 6, 2013 Time: 8:00 am, Pacific Daylight Time (San Francisco, GMT-07:00) Meeting Number: 640 049 742 Meeting Password: 1234 ------------------------------------------------------- To join the online meeting (Now from mobile devices!) ------------------------------------------------------- 1. Go to https://ietf.webex.com/ietf/j.php?ED=179545787&UID=1381218722&PW=NYTQ2YTA5MjY4&RT=MiM0 2. If requested, enter your name and email address. 3. If a password is required, enter the meeting password: 1234 4. Click "Join". To view in other time zones or languages, please click the link: https://ietf.webex.com/ietf/j.php?ED=179545787&UID=1381218722&PW=NYTQ2YTA5MjY4&ORT=MiM0 ------------------------------------------------------- To join the audio conference only ------------------------------------------------------- Call-in toll number (US/Canada): 1-650-479-3208 Access code:640 049 742 The IETF WebEx has a "use computer for audio" feature that allows a user to participate using their computer and a headset. However, the quality of the audio tends to be quite variable, and those who use this feature should mute themselves via the WebEx interface when not speaking to avoid causing echo. Users can also access the call-in number via Skype: 1. Bring up your Skype application. 2. Bring up your browser, and go to the WebEx URL. 3. Enter your name and email address. 4. Close the WebEx window prompting for a phone number. 5. Select the "info" tab at the top of the WebEx browser page. 6. Go to Skype, and dial the U.S. number from the meeting announcement. 7. Click on the DialPad tab on the Skype window. 8. Use the virtual keypad to enter the meeting number followed by #. 9. Use the virtual keypad to enter your attendee ID followed by #. ------------------------------------------------------- For assistance ------------------------------------------------------- 1. Go to https://ietf.webex.com/ietf/mc 2. On the left navigation bar, click "Support". You can contact me at: cmorgan@amsl.com 1-510-492-4085 To add this meeting to your calendar program (for example Microsoft Outlook), click this link: https://ietf.webex.com/ietf/j.php?ED=179545787&UID=1381218722&ICS=MI&LD=1&RD=2&ST=1&SHA2=AAAAAqaLd3iTjOQdFMoQ4QudQhNdYxPyqtufO60he9MbQwkT&RT=MiM0 The playback of UCF (Universal Communications Format) rich media files requires appropriate players. To view this type of rich media files in the meeting, please check whether you have the players installed on your computer by going to https://ietf.webex.com/ietf/systemdiagnosis.php. Sign up for a free trial of WebEx http://www.webex.com/go/mcemfreetrial http://www.webex.com CCP:+16504793208x640049742# IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the start of the recording or do not join the session. Please note that any such recordings may be subject to discovery in the event of litigation. --------------060305040005040003090209 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit
Topic: KITTEN WG Interim
Date: Monday, May 6, 2013
Time: 8:00 am, Pacific Daylight Time (San Francisco, GMT-07:00)
Meeting Number: 640 049 742
Meeting Password: 1234


-------------------------------------------------------
To join the online meeting (Now from mobile devices!)
-------------------------------------------------------
1. Go to https://ietf.webex.com/ietf/j.php?ED=179545787&UID=1381218722&PW=NYTQ2YTA5MjY4&RT=MiM0
2. If requested, enter your name and email address.
3. If a password is required, enter the meeting password: 1234
4. Click "Join".

To view in other time zones or languages, please click the link:
https://ietf.webex.com/ietf/j.php?ED=179545787&UID=1381218722&PW=NYTQ2YTA5MjY4&ORT=MiM0

-------------------------------------------------------
To join the audio conference only
-------------------------------------------------------
Call-in toll number (US/Canada): 1-650-479-3208

Access code:640 049 742
 
The IETF WebEx has a "use computer for audio" feature that allows a user
to participate using their computer and a headset.  However, the quality
of the audio tends to be quite variable, and those who use this feature
should mute themselves via the WebEx interface when not speaking to
avoid causing echo.

Users can also access the call-in number via Skype:

1.  Bring up your Skype application.
2.  Bring up your browser, and go to the WebEx URL.
3.  Enter your name and email address.
4.  Close the WebEx window prompting for a phone number.
5.  Select the "info" tab at the top of the WebEx browser page.
6.  Go to Skype, and dial the U.S. number from the meeting 
    announcement.
7.  Click on the DialPad tab on the Skype window.
8.  Use the virtual keypad to enter the meeting number followed by #.
9.  Use the virtual keypad to enter your attendee ID followed by #.
-------------------------------------------------------
For assistance
-------------------------------------------------------
1. Go to https://ietf.webex.com/ietf/mc
2. On the left navigation bar, click "Support".

You can contact me at:
cmorgan@amsl.com
1-510-492-4085

To add this meeting to your calendar program (for example Microsoft Outlook), click this link:
https://ietf.webex.com/ietf/j.php?ED=179545787&UID=1381218722&ICS=MI&LD=1&RD=2&ST=1&SHA2=AAAAAqaLd3iTjOQdFMoQ4QudQhNdYxPyqtufO60he9MbQwkT&RT=MiM0

The playback of UCF (Universal Communications Format) rich media files requires appropriate players. To view this type of rich media files in the meeting, please check whether you have the players installed on your computer by going to https://ietf.webex.com/ietf/systemdiagnosis.php.

Sign up for a free trial of WebEx
http://www.webex.com/go/mcemfreetrial

http://www.webex.com

CCP:+16504793208x640049742#

IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the start of the recording or do not join the session. Please note that any such recordings may be subject to discovery in the event of litigation.

--------------060305040005040003090209-- From kaduk@mit.edu Sun May 5 13:24:29 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0ED121F9740 for ; Sun, 5 May 2013 13:24:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y68-45ZUyrdz for ; Sun, 5 May 2013 13:24:24 -0700 (PDT) Received: from dmz-mailsec-scanner-1.mit.edu (DMZ-MAILSEC-SCANNER-1.MIT.EDU [18.9.25.12]) by ietfa.amsl.com (Postfix) with ESMTP id 19D9E21F96E4 for ; Sun, 5 May 2013 13:24:23 -0700 (PDT) X-AuditID: 1209190c-b7f566d000004c69-a9-5186bff7bf91 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 57.7E.19561.7FFB6815; Sun, 5 May 2013 16:24:23 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id r45KOMmE005570; Sun, 5 May 2013 16:24:22 -0400 Received: from multics.mit.edu (SYSTEM-LOW-SIPB.MIT.EDU [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id r45KOJm7009580 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 5 May 2013 16:24:21 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id r45KOJDK014078; Sun, 5 May 2013 16:24:19 -0400 (EDT) Date: Sun, 5 May 2013 16:24:19 -0400 (EDT) From: Benjamin Kaduk To: Nico Williams In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDIsWRmVeSWpSXmKPExsUixG6novt9f1ugwbaTvBZHN69isTh17Qib A5PHy1PnGD2WLPnJFMAUxWWTkpqTWZZapG+XwJXxbf8tpoIpPBXbV71lbWDs4Opi5OCQEDCR mDZBqIuRE8gUk7hwbz1bFyMXh5DAPkaJpY0roJwNjBJ9b06yQDgHmSQmH+hiA2kREqiX2Pt+ GguIzSKgJbF9wTJmEJtNQEVi5puNYDUiApoS1+ctBbOZBYQl1p+bAVYjLOAs0dp7lgnE5hQI lNi06QfYHF4BB4k/D9+zQswPkNg1pQWsRlRAR2L1/ilQNYISJ2c+YYGYaSnxb+0v1gmMgrOQ pGYhSS1gZFrFKJuSW6Wbm5iZU5yarFucnJiXl1qka6iXm1mil5pSuokRFKickjw7GN8cVDrE KMDBqMTDe6O2NVCINbGsuDL3EKMkB5OSKO/MfW2BQnxJ+SmVGYnFGfFFpTmpxYcYJTiYlUR4 ffYC5XhTEiurUovyYVLSHCxK4ryXU276CwmkJ5akZqemFqQWwWRlODiUJHj9gREpJFiUmp5a kZaZU4KQZuLgBBnOAzTcBqSGt7ggMbc4Mx0if4pRUUqcdx7IRQIgiYzSPLheWCJ5xSgO9Iow LwtIOw8wCcF1vwIazAQ0eGlWM8jgkkSElFQDY8+VVbv3nfCW8g2c4PldKtfgkvGUlvCr6xcv Ts05y9qys6BB0+739jv3kjVPnLk16+LH4AdSWb/OBV3/xhxTJOjsoSf41bDpgazfHYlLezXY OqdPVlG52uSoPV1q9Qrm0kWrN/iUeJ3eti8p4OVhbymT3TIH+ev6eAVY71ndz5r/VCe16p7J BiWW4oxEQy3mouJEALkVfaT/AgAA Cc: kitten@ietf.org Subject: Re: [kitten] -02 of GSS_C_CHANNEL_BOUND_FLAG I-D submitted X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 May 2013 20:24:29 -0000 On Fri, 22 Feb 2013, Nico Williams wrote: > Version -02, using the "empty sec context constructor" design has been > submitted. > > http://www.ietf.org/id/draft-williams-kitten-channel-bound-flag-02.txt > http://tools.ietf.org/html/draft-williams-kitten-channel-bound-flag-02 > http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-williams-kitten-channel-bound-flag-02.txt > > (Hmm, I just realized that we should say what happens when > GSS_Delete_sec_context() is called on an empty sec context handle, > namely that no deletion context token is to be generated.) (Yes, you should.) It looks like I never commented on the channel bound flag on-list. The concept of the -02 draft, with empty security context handles, does seem more appealing than the -00's flags on credential handles. In 2.1, a NULL context is usually spelled GSS_C_NO_CONTEXT, and it might be good to explicitly call out that this document is changing the expected behavior of GSS_{Init,Accept}_sec_context() (as opposed to doing so in passing). In 2.2.1, I assume that the use of 64-bit types for the flags arguments (as opposed to the 32-bit types in the C bindings for gss_init_sec_context()) is an intentional attempt to increase the number of flags available? In section 3, the fourth bullet point (applications using the channel_bound flag) does not specify the behavior when both peers provide bindings but the bindings differ. This case is covered by the first bullet point, but a reminder might help the reader. -Ben From kaduk@mit.edu Sun May 5 14:53:39 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6692A21F977B for ; Sun, 5 May 2013 14:53:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E0y04pCg3Brh for ; Sun, 5 May 2013 14:53:32 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (DMZ-MAILSEC-SCANNER-2.MIT.EDU [18.9.25.13]) by ietfa.amsl.com (Postfix) with ESMTP id 4FEA621F972F for ; Sun, 5 May 2013 14:53:31 -0700 (PDT) X-AuditID: 1209190d-b7f716d000005557-87-5186d4dae1c9 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 84.B6.21847.AD4D6815; Sun, 5 May 2013 17:53:30 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id r45LrU4w009740 for ; Sun, 5 May 2013 17:53:30 -0400 Received: from multics.mit.edu (SYSTEM-LOW-SIPB.MIT.EDU [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id r45LrScO004459 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sun, 5 May 2013 17:53:29 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id r45LrSdn025490; Sun, 5 May 2013 17:53:28 -0400 (EDT) Date: Sun, 5 May 2013 17:53:28 -0400 (EDT) From: Benjamin Kaduk To: kitten@ietf.org In-Reply-To: <20130411064110.29519.86993.idtracker@ietfa.amsl.com> Message-ID: References: <20130411064110.29519.86993.idtracker@ietfa.amsl.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGIsWRmVeSWpSXmKPExsUixG6nrnvrSlugwb8NuhZHN69icWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxuyr09kLXgpWPDx/n72B8RxvFyMHh4SAicTJiZJdjJxAppjE hXvr2boYuTiEBPYxSlzd85oFwjnGKPGz+wwrhHOdSWJy4yQ2kBYhgXqJE5PvM4LYLAJaEu9/ 7GcGsdkEVCRmvtkIViMiICyxe+s7sLiwgKPEuwcf2UFsTgEniekP9zGB2LwCDhKTf81jhpjp KHHryXuwXlEBHYnV+6ewQNQISpyc+QTMZhawlPi39hfrBEaBWUhSs5CkFjAyrWKUTcmt0s1N zMwpTk3WLU5OzMtLLdI10svNLNFLTSndxAgKPk5J3h2M7w4qHWIU4GBU4uG9UdsaKMSaWFZc mXuIUZKDSUmU1/pEW6AQX1J+SmVGYnFGfFFpTmrxIUYJDmYlEV6fvUA53pTEyqrUonyYlDQH i5I475WUm/5CAumJJanZqakFqUUwWRkODiUJ3pDLQI2CRanpqRVpmTklCGkmDk6Q4TxAwx1A aniLCxJzizPTIfKnGBWlxHl/XAJKCIAkMkrz4HphyeEVozjQK8K8ziDtPMDEAtf9CmgwE9Dg pVnNIINLEhFSUg2MrdIL//gVvvg8MU/wvfpzrWcTt3EmiWldsptV/s1n3vNQMZ9luX9ly72N PwV4dHu7fVbQmsc9t954mVPD2sU7Ln74sfleCH9/9sE6iZ6gGWe5vt16tzxqhm0hS739DW8z pY/vQ//8mfNlEn9N3qQHYvJtt9eq3nsy9RrXdLPpioG1beK2amdYlFiKMxINtZiLihMBBcHb KukCAAA= Subject: Re: [kitten] I-D Action: draft-ietf-kitten-iakerb-00.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 May 2013 21:53:39 -0000 On Wed, 10 Apr 2013, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Common Authentication Technology Next Generation Working Group of the IETF. > > Title : Initial and Pass Through Authentication Using Kerberos V5 and the GSS- API (IAKERB) > Author(s) : Jim Schaad > Larry Zhu > Jeffery Altman > Filename : draft-ietf-kitten-iakerb-00.txt > Pages : 9 > Date : 2013-04-10 > > Abstract: > This document defines extensions to the Kerberos protocol and the > GSS-API Kerberos mechanism that enable a GSS-API Kerberos client to > exchange messages with the KDC using the GSS-API acceptor as the I think the last "the" on this line should be "a". Likewise for where "the proxy" appears in the introduction's last paragraph. > proxy, by encapsulating the Kerberos messages inside GSS-API tokens. > With these extensions a client can obtain Kerberos tickets for > services where the KDC is not accessible to the client, but is > accessible to the application server. Other comments: Also in the introduction, no expansion or motivation for the name/term "IAKERB" is given when it is first introduced. (None is given elsewhere in the document that I can see, either.) The top of page 4 seems to have some editing errors, referring to a "GSS-API server" (not acceptor), and then in the following paragraph does not specify that the KRB_ERROR message should be used in the IAKERB_PROXY message in place of an actual KDC reply. Hmm, "GSS-API server" appears in at least one other place as well. In the security considerations, the sentence "To reduce attack surface, firewall filters can be applied to allow from which hosts the client requests can be proxied and the proxy can further restrict the set of realms to which the requests can be proxied." has an unusual, perhaps even incorrect, sentence structure (in particular "allow from which hosts"). I think it would be feasible to extract the necessary bits from PKU2U and include them in this document, but defer to tomorrow's discussion. -Ben From kaduk@mit.edu Sun May 5 15:02:57 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE28C21F977C for ; Sun, 5 May 2013 15:02:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.524 X-Spam-Level: X-Spam-Status: No, score=-3.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7aYKTEhncDBw for ; Sun, 5 May 2013 15:02:52 -0700 (PDT) Received: from dmz-mailsec-scanner-3.mit.edu (DMZ-MAILSEC-SCANNER-3.MIT.EDU [18.9.25.14]) by ietfa.amsl.com (Postfix) with ESMTP id 2DB4221F9777 for ; Sun, 5 May 2013 15:02:52 -0700 (PDT) X-AuditID: 1209190e-b7f4f6d000005142-1b-5186d70b1299 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id E4.4D.20802.B07D6815; Sun, 5 May 2013 18:02:51 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id r45M2oj8012643; Sun, 5 May 2013 18:02:50 -0400 Received: from multics.mit.edu (SYSTEM-LOW-SIPB.MIT.EDU [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id r45M2mOT007210 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 5 May 2013 18:02:50 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id r45M2mpQ026643; Sun, 5 May 2013 18:02:48 -0400 (EDT) Date: Sun, 5 May 2013 18:02:47 -0400 (EDT) From: Benjamin Kaduk To: Nico Williams In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDIsWRmVeSWpSXmKPExsUixG6nost9vS3QoOu5kMXRzatYLE5dO8Lm wOTx8tQ5Ro8lS34yBTBFcdmkpOZklqUW6dslcGXsa1vJWPCbsaK54wxzA+MJxi5GTg4JAROJ m923oWwxiQv31rN1MXJxCAnsY5SYdHATM4SzgVHi0q19LBDOQSaJ3v/72UBahATqJZ6ee8IM YrMIaEn0XD7JCmKzCahIzHyzEaxGREBT4vq8pWA2s4CwxPpzM4DqOTiEBfQkDvTzg4Q5BQIl Lr+/AjaGV8BBYuqp44wQ4wMkjqyeAjZSVEBHYvX+KSwQNYISJ2c+YYEYaSlx7s91tgmMgrOQ pGYhSS1gZFrFKJuSW6Wbm5iZU5yarFucnJiXl1qka6yXm1mil5pSuokRFKicknw7GL8eVDrE KMDBqMTDe6O2NVCINbGsuDL3EKMkB5OSKK/1ibZAIb6k/JTKjMTijPii0pzU4kOMEhzMSiK8 PnuBcrwpiZVVqUX5MClpDhYlcd4rKTf9hQTSE0tSs1NTC1KLYLIyHBxKErzK14AaBYtS01Mr 0jJzShDSTBycIMN5gIb7gtTwFhck5hZnpkPkTzEqSonztl0FSgiAJDJK8+B6YYnkFaM40CvC vCIg7TzAJATX/QpoMBPQ4KVZzSCDSxIRUlINjM49Ea4pGQtXlZh0yifs7932a84TBul13rvO Vz1y77cKW6f6xsXiWkrE8voPbGdfSWmLyX+9JeqZ9ThguhPXkScLObcUGVW9VGeXClmsq+kx 0+t529ncE387s79NOh6/jY9V+v+33VMeL9LOm/BV22hlVJyv0f/6zx4pxXv2/tJvaBWdalp1 R4mlOCPRUIu5qDgRAM4UoOr/AgAA Cc: kitten@ietf.org Subject: Re: [kitten] Simplified and async API X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 May 2013 22:02:58 -0000 On Fri, 22 Feb 2013, Nico Williams wrote: > Too late for submitting -00s. So here: > > https://raw.github.com/nicowilliams/kitten/master/gss-step-ctx.txt Did this ever get submitted as an I-D? I don't see it on the datatracker... -Ben From internet-drafts@ietf.org Sun May 5 15:35:03 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 381FC21F977D; Sun, 5 May 2013 15:35:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.544 X-Spam-Level: X-Spam-Status: No, score=-102.544 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F0UElhMlK48X; Sun, 5 May 2013 15:35:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BFFF621F9772; Sun, 5 May 2013 15:35:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.44.p5 Message-ID: <20130505223502.10161.68731.idtracker@ietfa.amsl.com> Date: Sun, 05 May 2013 15:35:02 -0700 Cc: kitten@ietf.org Subject: [kitten] I-D Action: draft-ietf-kitten-sasl-saml-ec-08.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 May 2013 22:35:03 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Common Authentication Technology Next Gen= eration Working Group of the IETF. Title : SAML Enhanced Client SASL and GSS-API Mechanisms Author(s) : Scott Cantor Simon Josefsson Filename : draft-ietf-kitten-sasl-saml-ec-08.txt Pages : 32 Date : 2013-05-05 Abstract: Security Assertion Markup Language (SAML) 2.0 is a generalized framework for the exchange of security-related information between asserting and relying parties. Simple Authentication and Security Layer (SASL) and the Generic Security Service Application Program Interface (GSS-API) are application frameworks to facilitate an extensible authentication model. This document specifies a SASL and GSS-API mechanism for SAML 2.0 that leverages the capabilities of a SAML-aware "enhanced client" to address significant barriers to federated authentication in a manner that encourages reuse of existing SAML bindings and profiles designed for non-browser scenarios. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-kitten-sasl-saml-ec There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-kitten-sasl-saml-ec-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-kitten-sasl-saml-ec-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ghudson@mit.edu Mon May 6 11:02:36 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D28B21F84CE for ; Mon, 6 May 2013 11:02:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NvODmliPV3Bj for ; Mon, 6 May 2013 11:02:30 -0700 (PDT) Received: from dmz-mailsec-scanner-7.mit.edu (DMZ-MAILSEC-SCANNER-7.MIT.EDU [18.7.68.36]) by ietfa.amsl.com (Postfix) with ESMTP id 0230E21F90DF for ; Mon, 6 May 2013 11:02:26 -0700 (PDT) X-AuditID: 12074424-b7f8c6d0000028c4-89-5187f0325bd7 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 12.AE.10436.230F7815; Mon, 6 May 2013 14:02:26 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id r46I2PQ1029396 for ; Mon, 6 May 2013 14:02:25 -0400 Received: from [18.101.8.104] (VPN-18-101-8-104.MIT.EDU [18.101.8.104]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id r46I2NFU015144 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 6 May 2013 14:02:25 -0400 Message-ID: <5187F02F.3070105@mit.edu> Date: Mon, 06 May 2013 14:02:23 -0400 From: Greg Hudson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130404 Thunderbird/17.0.5 MIME-Version: 1.0 To: kitten@ietf.org References: <20130411064110.29519.54840.idtracker@ietfa.amsl.com> <001201ce3695$c13005e0$439011a0$@augustcellars.com> <005301ce36e6$265d9bd0$7318d370$@augustcellars.com> <51671F8E.3050701@mit.edu> <02cf01ce3a2c$902997a0$b07cc6e0$@augustcellars.com> <3151B618-970E-4F21-9C8C-E21984F9024D@padl.com> In-Reply-To: <3151B618-970E-4F21-9C8C-E21984F9024D@padl.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrAIsWRmVeSWpSXmKPExsUixG6nrmv0oT3QYOMyVoujm1exODB6LFny kymAMYrLJiU1J7MstUjfLoErY/n/++wFHRwV5xt2MTcwnmHrYuTkkBAwkXg17wKULSZx4d56 IJuLQ0hgH6PEkQkvWSGcY4wSGzecZIRwbjJJ3L/4jAWkhVdATaJv/2NmEJtFQFVi4ctPTCA2 m4CyxMGz38BqRAVCJE5/bmKGqBeUODnzCVhcREBYYvfWd2BxYYEgiQWbDrBALFjBJDFl2VdG kASngI3EsoOnWCDuk5RYNK0TzGYW0JF41/eAGcKWl9j+dg7zBEbBWUh2zEJSNgtJ2QJG5lWM sim5Vbq5iZk5xanJusXJiXl5qUW65nq5mSV6qSmlmxjBAeuisoOx+ZDSIUYBDkYlHl7FU+2B QqyJZcWVuYcYJTmYlER5Od4BhfiS8lMqMxKLM+KLSnNSiw8xSnAwK4nwVq4ByvGmJFZWpRbl w6SkOViUxHmvp9z0FxJITyxJzU5NLUgtgsnKcHAoSfDOBRkqWJSanlqRlplTgpBm4uAEGc4D NHw7SA1vcUFibnFmOkT+FKOilDjv1rdACQGQREZpHlwvLKG8YhQHekUYop0HmIzgul8BDWYC GpzABza4JBEhJdXAOPtA2E5G7fzpz9+YvX6l9FWhK/teyvWvJ7+8ZAow3LChtvLZuqsH7st7 POnNXr3cf0tSxt0u698X7i4s8Txm+nf70gma64uP7fR6sD+4y95tEe9maz2bPzfWHPG+vzuQ kS9LzfKy4bM/PzYt3pXMHdF467Gej+ERWadP7Icmt8bd3hPkELT7CIsSS3FGoqEWc1FxIgDE ZP2rAwMAAA== Subject: Re: [kitten] New Version Notification for draft-ietf-kitten-iakerb-00.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2013 18:02:36 -0000 Today I did a more careful comparison of draft-zhu-ws-kerb vs. draft-ietf-kitten-iakerb, and uncovered a second superficial difference. draft-zhu-ws-kerb states: The initial context establishment token of IAKERB MUST have the generic token framing described in section 3.1 of [RFC2743] with the mechanism OID being id-kerberos-iakerb, and any subsequent IAKERB context establishment token MUST NOT have this token framing. while draft-kitten-ietf-iakerb states: All context establishment token of IAKERB MUST have the generic token framing described in section 3.1 of [RFC2743] with the mechanism OID being id-kerberos-iakerb. Luckily, MIT's implementation allows framing to be present for all context establishment tokens. This makes the situation tractable; we can change our code to always generate framing, without breaking compatibility with ourselves. I will send a separate message (in a different thread) with a list of options for handling the compatibility differences. From ghudson@mit.edu Mon May 6 11:34:37 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 122FF21F930C for ; Mon, 6 May 2013 11:34:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gi3W29dtm8s7 for ; Mon, 6 May 2013 11:34:31 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (DMZ-MAILSEC-SCANNER-2.MIT.EDU [18.9.25.13]) by ietfa.amsl.com (Postfix) with ESMTP id 7947621F92F5 for ; Mon, 6 May 2013 11:34:31 -0700 (PDT) X-AuditID: 1209190d-b7f716d000005557-e8-5187f7b60518 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 20.F1.21847.6B7F7815; Mon, 6 May 2013 14:34:30 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id r46IYTpI028616 for ; Mon, 6 May 2013 14:34:30 -0400 Received: from localhost (EQUAL-RITES.MIT.EDU [18.18.1.59]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id r46IYS6I006783 for ; Mon, 6 May 2013 14:34:29 -0400 From: Greg Hudson To: kitten@ietf.org Date: Mon, 06 May 2013 14:34:23 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCIsWRmVeSWpSXmKPExsUixCmqrLvte3ugwf8zChZHN69icWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxpOtb5kKTvFVXJpym7WB8Q53FyMnh4SAicTCvk0sELaYxIV7 69lAbCGBfYwSBw97QNjHGCXerSvsYuQCstuZJA49PMAEkmATUJY4ePYbWLOIgLDE7q3vmEFs YQF9ib9THrCD2CwCqhLz3x8BGsrBwStgKHHtWw5ImFdAUOLkzCdgrcwCWhI3/r1kmsDIMwtJ ahaS1AJGplWMsim5Vbq5iZk5xanJusXJiXl5qUW6Rnq5mSV6qSmlmxjBgSHJu4Px3UGlQ4wC HIxKPLwKp9oDhVgTy4orcw8xSnIwKYnyhnwFCvEl5adUZiQWZ8QXleakFh9ilOBgVhLhrVwD lONNSaysSi3Kh0lJc7AoifNeSbnpLySQnliSmp2aWpBaBJOV4eBQkuAN+gbUKFiUmp5akZaZ U4KQZuLgBBnOAzT8PUgNb3FBYm5xZjpE/hSjopQ4by1IQgAkkVGaB9cLi9xXjOJArwjzeoJU 8QCjHq77FdBgJqDBCXxgg0sSEVJSDYxm27tO7eA8Nt9SVqJ9x6033rZuGzuOPfrDP1PnzhSO 9NNWra6Tna+6Ot2LSLh2cdLZZofrhzWPrVKYuUWAqWWm7a57CT9vvtPxZRb91/XOVe3Cq7rG e1Fn1n7yf19hdLgneWef1eY9Qscui/+0lX7nP+do4V3DbZxSljw2kobrtspme78R23BXiaU4 I9FQi7moOBEAYTzYALcCAAA= Subject: [kitten] Options for IAKERB compatibility issue X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2013 18:34:37 -0000 Here are some options for addressing the superficial incompatibilities between MIT's implementation of draft-zhu-ws-kerb and the current draft-kitten-ietf-iakerb (see [1] and [2] for details). 1. We can ignore the problem. MIT's implementation won't be compatible with the standard and we won't be able to make it compatible without breaking compatibility with ourselves. 2. We can revert to the draft-zhu-ws-kerb superficialities. This works great for MIT, but presents OSX with the same problem as MIT would have in #1. 3. We can make the standard semi-compatible with both implementations: - always generate generic token framing - process framed or unframed messages after the first initiator token - acceptors must process either kind of finished extension - initiators may send either kind of finished extension A standard acceptor would work with MIT and OSX initiators. A standard initiator can only be compatible with MIT or OSX acceptors (it has to guess which type of finished extension to send), but will always be compatible with a standard acceptor. 4. Possibly in addition to #3, we could extend IAKERB-HEADER with a new field that acts as an "I implement the standard" cue. This option would give MIT a path to generating the pku2u-style of finished extension, but it doesn't create a better compatibility matrix than just requiring acceptors to allow both kinds of finished extension. 5. We can define a new mech OID for the standard. I don't like this option because I don't like proliferating krb5 mech OIDs. It also means the standard wouldn't interoperate with either OSX's or Apple's implementation. [1] http://www.ietf.org/mail-archive/web/kitten/current/msg03919.html [2] http://www.ietf.org/mail-archive/web/kitten/current/msg03984.html From nico@cryptonector.com Mon May 6 11:56:51 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 189EA21F90EB for ; Mon, 6 May 2013 11:56:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.622 X-Spam-Level: X-Spam-Status: No, score=0.622 tagged_above=-999 required=5 tests=[FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bntijHvidiSR for ; Mon, 6 May 2013 11:56:46 -0700 (PDT) Received: from homiemail-a95.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id 3AD7421F90CD for ; Mon, 6 May 2013 11:56:43 -0700 (PDT) Received: from homiemail-a95.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a95.g.dreamhost.com (Postfix) with ESMTP id BBC821E069 for ; Mon, 6 May 2013 11:56:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=ft8o8KTcKid8ZqEm/tyj pU0QHZI=; b=JkLkeWgTTNHahe3fqSXDHwODFWHClCzfUxk7dIYZLarLahXstD4J U7OvbhL6VKCLtk/w4tn+/KRC0cckfagGLpRgmp2mq/EFozXExNcI2lbHlWrA2DrY JIqu/3yNrnxVi/UcFocoLjEzss3gzVAL0fXXuT5tQlNoS5gJMZGLDG8= Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com [74.125.82.45]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a95.g.dreamhost.com (Postfix) with ESMTPSA id 5E7E21E059 for ; Mon, 6 May 2013 11:56:42 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id l18so3733093wgh.0 for ; Mon, 06 May 2013 11:56:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=cj0rDDjTRknPqp9FD3QqyRWNIj5UjH14QYBD/emewvE=; b=BajxQYUoUPdcNiVFSWPAhRQLz4d4OslXFMUX9Jxn1KP/k/c+CZkdzRQSmMe9oxIDQP tHMPBmFgQ7+UYpqbdEhKiP3yRq5PxfMpMOJuJ+cH4qLmUHTFvrWpWV5QZWODHEZEl3f9 M3ek0bZ+xaytRjkTIF7JEwUrxaRvHoDDDbwsfxYS260WiFQCwunJOahNQjzD6EcvnGNS cnP54v8mffakh/SBy5Q1wkr94h9KPC5z/pq+knn44t9PDHSm4ZdkE/mDQ6Hore5A9ANR YVTqLMi1s6CqIzyQOYmUg8n8yw7jdXDtVTu4d+RUSBqquqwmHQD+FXlxBtlWkrhviENa iShg== MIME-Version: 1.0 X-Received: by 10.180.73.173 with SMTP id m13mr10219113wiv.27.1367866601185; Mon, 06 May 2013 11:56:41 -0700 (PDT) Received: by 10.216.111.132 with HTTP; Mon, 6 May 2013 11:56:41 -0700 (PDT) In-Reply-To: References: Date: Mon, 6 May 2013 13:56:41 -0500 Message-ID: From: Nico Williams To: Greg Hudson Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org Subject: Re: [kitten] Options for IAKERB compatibility issue X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2013 18:56:51 -0000 On Mon, May 6, 2013 at 1:34 PM, Greg Hudson wrote: > 5. We can define a new mech OID for the standard. I don't like this > option because I don't like proliferating krb5 mech OIDs. It also > means the standard wouldn't interoperate with either OSX's or Apple's > implementation. The new mech OID would interop with one of the existing implementations, and the other implementation would have to support the old and new mech OIDs in order to get past non-iteroperability. What's wrong with that? In any case, something has to be done, some tears may have to be shed. It'd be useful to have an idea of what deployments exist. Perhaps we should start by polling for deployments. Nico -- From ghudson@mit.edu Tue May 7 10:38:26 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 976FC21F9254 for ; Tue, 7 May 2013 10:38:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MtBqhAUXRhnI for ; Tue, 7 May 2013 10:38:20 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (DMZ-MAILSEC-SCANNER-6.MIT.EDU [18.7.68.35]) by ietfa.amsl.com (Postfix) with ESMTP id 763D021F93B4 for ; Tue, 7 May 2013 10:38:12 -0700 (PDT) X-AuditID: 12074423-b7f826d000001438-1a-51893c03ed23 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id EB.ED.05176.30C39815; Tue, 7 May 2013 13:38:11 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id r47HcBIs014918; Tue, 7 May 2013 13:38:11 -0400 Received: from [18.189.54.192] ([18.189.54.192]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id r47Hc84u003731 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 7 May 2013 13:38:10 -0400 Message-ID: <51893C00.7090808@mit.edu> Date: Tue, 07 May 2013 13:38:08 -0400 From: Greg Hudson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130404 Thunderbird/17.0.5 MIME-Version: 1.0 To: Nico Williams References: In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpgleLIzCtJLcpLzFFi42IR4hRV1mW26Qw06Ow3sTi6eRWLxalrR9gc mDxenjrH6LFkyU+mAKYoLpuU1JzMstQifbsErownvw6yFcxiq3hw6ThzA+Nvli5GTg4JAROJ pbO3sELYYhIX7q1nA7GFBPYxShx7wgxhb2CUuHMysYuRC8hewyTx9NlydpAEr4CaxI75D8GK WARUJd6d/wnWzCagLHHw7DewBaICIRKnPzcxQ9QLSpyc+QQsLiKgKXF93lKwemYBYYkL2/cC HcHBISxgI/FhSiLE3jKJVX1fwMo5BQIlVm19BHWzpMSiaZ0sIOXMAuoS6+cJQUyRl9j+dg7z BEahWUiWzUKomoWkagEj8ypG2ZTcKt3cxMyc4tRk3eLkxLy81CJdM73czBK91JTSTYyggGZ3 Ud7B+Oeg0iFGAQ5GJR5eC+7OQCHWxLLiytxDjJIcTEqivF+NgEJ8SfkplRmJxRnxRaU5qcWH GCU4mJVEeIUUgHK8KYmVValF+TApaQ4WJXHeayk3/YUE0hNLUrNTUwtSi2CyMhwcShK8zcZA jYJFqempFWmZOSUIaSYOTpDhPEDDc61BhhcXJOYWZ6ZD5E8xKkqJ8xqDNAuAJDJK8+B6YQnn FaM40CvCEO08wGQF1/0KaDAT0OAEvnaQwSWJCCmpBkaBLc/dRZwvR6of7Vw8f/o15+Inid16 im5/C/M+cB3cc+AUe1Lkqzv+/LF7Lkx35i5c5jX7KKOD/p3aCOcr2uFCK6/v3c4mZxkiMs/0 YapF/o0Nv6dIPhP65jnv2vxAPfUN+7d8quiWVetdGsrhxWZo1e6ifUbk16RZR4IXnPqe8qeb kdG7LEyJpTgj0VCLuag4EQD0cxtoEwMAAA== Cc: kitten@ietf.org Subject: Re: [kitten] Options for IAKERB compatibility issue X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 17:38:26 -0000 On 05/06/2013 02:56 PM, Nico Williams wrote: > On Mon, May 6, 2013 at 1:34 PM, Greg Hudson wrote: >> 5. We can define a new mech OID for the standard. I don't like this >> option because I don't like proliferating krb5 mech OIDs. It also >> means the standard wouldn't interoperate with either OSX's or Apple's >> implementation. > The new mech OID would interop with one of the existing > implementations Not under any reasonable definition of "interoperate". If the standard uses a different OID from 1.3.6.1.5.2.5, then an implementation of the standard won't interoperate with an existing MIT krb5 or OSX implementation. One could potentially use the same or similar code for both OIDs, but that's not interoperating; that's code sharing. From lha@kth.se Tue May 7 11:02:30 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D766C21F946C for ; Tue, 7 May 2013 11:02:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.948 X-Spam-Level: X-Spam-Status: No, score=-1.948 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id huAJVc28he1F for ; Tue, 7 May 2013 11:02:24 -0700 (PDT) Received: from smtp-3.sys.kth.se (smtp-3.sys.kth.se [IPv6:2001:6b0:1:1300:250:56ff:fea6:2de2]) by ietfa.amsl.com (Postfix) with ESMTP id 6613721F942D for ; Tue, 7 May 2013 11:02:23 -0700 (PDT) Received: from mailscan-3.sys.kth.se (mailscan-3.sys.kth.se [130.237.48.170]) by smtp-3.sys.kth.se (Postfix) with ESMTP id 742575B7; Tue, 7 May 2013 20:02:21 +0200 (CEST) X-Virus-Scanned: by amavisd-new at kth.se Received: from smtp-3.sys.kth.se ([130.237.48.192]) by mailscan-3.sys.kth.se (mailscan-3.sys.kth.se [130.237.48.170]) (amavisd-new, port 10024) with ESMTP id DZhKou4c5w8E; Tue, 7 May 2013 20:02:17 +0200 (CEST) X-KTH-Auth: lha [2620:149:4:1b03:d88:9e8b:bf3b:3d46] X-KTH-mail-from: lha@kth.se Received: from [IPv6:2620:149:4:1b03:d88:9e8b:bf3b:3d46] (unknown [IPv6:2620:149:4:1b03:d88:9e8b:bf3b:3d46]) by smtp-3.sys.kth.se (Postfix) with ESMTPSA; Tue, 7 May 2013 20:02:10 +0200 (CEST) Content-Type: multipart/alternative; boundary="Apple-Mail=_F8A21F4B-CAB2-445F-B8DB-36CB24DA0477" Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1750\)) From: =?iso-8859-1?Q?Love_H=F6rnquist_=C5strand?= In-Reply-To: Date: Tue, 7 May 2013 11:02:05 -0700 Message-Id: <4969FAFD-094B-4774-B3B9-9B611FBF821A@kth.se> References: To: Greg Hudson X-Mailer: Apple Mail (2.1750) Cc: kitten@ietf.org Subject: Re: [kitten] Options for IAKERB compatibility issue X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 18:02:31 -0000 --Apple-Mail=_F8A21F4B-CAB2-445F-B8DB-36CB24DA0477 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 2 is not an option, its 5 or 1. prefer 1. doubtless after doing interop = testing we'll find more issues. Love 6 maj 2013 kl. 11:34 skrev Greg Hudson : > Here are some options for addressing the superficial incompatibilities > between MIT's implementation of draft-zhu-ws-kerb and the current > draft-kitten-ietf-iakerb (see [1] and [2] for details). >=20 > 1. We can ignore the problem. MIT's implementation won't be = compatible > with the standard and we won't be able to make it compatible without > breaking compatibility with ourselves. >=20 > 2. We can revert to the draft-zhu-ws-kerb superficialities. This = works > great for MIT, but presents OSX with the same problem as MIT would > have in #1. >=20 > 3. We can make the standard semi-compatible with both implementations: > - always generate generic token framing > - process framed or unframed messages after the first initiator = token > - acceptors must process either kind of finished extension > - initiators may send either kind of finished extension > A standard acceptor would work with MIT and OSX initiators. A > standard initiator can only be compatible with MIT or OSX acceptors > (it has to guess which type of finished extension to send), but will > always be compatible with a standard acceptor. >=20 > 4. Possibly in addition to #3, we could extend IAKERB-HEADER with a = new > field that acts as an "I implement the standard" cue. This option > would give MIT a path to generating the pku2u-style of finished > extension, but it doesn't create a better compatibility matrix than > just requiring acceptors to allow both kinds of finished extension. >=20 > 5. We can define a new mech OID for the standard. I don't like this > option because I don't like proliferating krb5 mech OIDs. It also > means the standard wouldn't interoperate with either OSX's or = Apple's > implementation. >=20 > [1] http://www.ietf.org/mail-archive/web/kitten/current/msg03919.html > [2] http://www.ietf.org/mail-archive/web/kitten/current/msg03984.html > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten --Apple-Mail=_F8A21F4B-CAB2-445F-B8DB-36CB24DA0477 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

2 is not an option, its 5 or 1. = prefer 1. doubtless after doing interop testing we'll find more = issues.

Love


6 = maj 2013 kl. 11:34 skrev Greg Hudson <ghudson@MIT.EDU>:

Here are some = options for addressing the superficial incompatibilities
between = MIT's implementation of draft-zhu-ws-kerb and the = current
draft-kitten-ietf-iakerb (see [1] and [2] for = details).

1. We can ignore the problem.  MIT's = implementation won't be compatible
  with the standard and = we won't be able to make it compatible without
  breaking = compatibility with ourselves.

2. We can revert to the = draft-zhu-ws-kerb superficialities.  This = works
  great for MIT, but presents OSX with the same = problem as MIT would
  have in #1.

3. We can make = the standard semi-compatible with both implementations:
  - = always generate generic token framing
  - process framed or = unframed messages after the first initiator token
  - = acceptors must process either kind of finished = extension
  - initiators may send either kind of finished = extension
  A standard acceptor would work with MIT and OSX = initiators.  A
  standard initiator can only be = compatible with MIT or OSX acceptors
  (it has to guess = which type of finished extension to send), but = will
  always be compatible with a standard = acceptor.

4. Possibly in addition to #3, we could extend = IAKERB-HEADER with a new
  field that acts as an "I = implement the standard" cue.  This option
  would give = MIT a path to generating the pku2u-style of = finished
  extension, but it doesn't create a better = compatibility matrix than
  just requiring acceptors to = allow both kinds of finished extension.

5. We can define a new = mech OID for the standard.  I don't like this
  option = because I don't like proliferating krb5 mech OIDs.  It = also
  means the standard wouldn't interoperate with either = OSX's or Apple's
  implementation.

[1] http://www.ietf.org/mail-archive/web/kitten/current/msg03919.html
= [2] http://www.ietf.org/mail-archive/web/kitten/current/msg03984.html
= _______________________________________________
Kitten mailing = list
Kitten@ietf.org
https://www.ietf.org= /mailman/listinfo/kitten

= --Apple-Mail=_F8A21F4B-CAB2-445F-B8DB-36CB24DA0477-- From ghudson@mit.edu Tue May 7 11:16:26 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E147A21F90D2 for ; Tue, 7 May 2013 11:16:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qt0NPpUVWuw3 for ; Tue, 7 May 2013 11:16:20 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (DMZ-MAILSEC-SCANNER-2.MIT.EDU [18.9.25.13]) by ietfa.amsl.com (Postfix) with ESMTP id 5281E21F901F for ; Tue, 7 May 2013 11:16:20 -0700 (PDT) X-AuditID: 1209190d-b7f716d000005557-de-518944f3d601 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 8D.89.21847.3F449815; Tue, 7 May 2013 14:16:19 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id r47IGIcP020508; Tue, 7 May 2013 14:16:18 -0400 Received: from [18.189.54.192] ([18.189.54.192]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id r47IGGZq024243 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 7 May 2013 14:16:17 -0400 Message-ID: <518944F0.8050504@mit.edu> Date: Tue, 07 May 2013 14:16:16 -0400 From: Greg Hudson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130404 Thunderbird/17.0.5 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Love_H=F6rnquist_=C5strand?= References: <4969FAFD-094B-4774-B3B9-9B611FBF821A@kth.se> In-Reply-To: <4969FAFD-094B-4774-B3B9-9B611FBF821A@kth.se> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmleLIzCtJLcpLzFFi42IR4hRV1v3s0hlosLdD1OLo5lUsFhfOqjow eSxZ8pPJo/v1RsYApigum5TUnMyy1CJ9uwSujMWdDSwFNxkrXjw4xtzAuJKxi5GTQ0LARKJv wwU2CFtM4sK99UA2F4eQwD5GiQnPNrNDOBsYJT6evcYI4axhkjjx7Tc7SAuvgJrEul93wGwW AVWJ11Pms4DYbALKEgfPfgOzRQVCJE5/bmKGqBeUODnzCVhcRMBG4vO3RUwgNrOAtcTRD/eA ajg4hIHiH6YkgoSFBOIl9tw9AXYdp4CVxJ8dU5ggLpWUWDStkwWiVUfiXd8DZghbXqJ562zm CYxCs5Bsm4WkbBaSsgWMzKsYZVNyq3RzEzNzilOTdYuTE/PyUot0jfRyM0v0UlNKNzGCw1qS dwfju4NKhxgFOBiVeHgfcHQGCrEmlhVX5h5ilORgUhLl/WoEFOJLyk+pzEgszogvKs1JLT7E KMHBrCTCK6QAlONNSaysSi3Kh0lJc7AoifNeSbnpLySQnliSmp2aWpBaBJOV4eBQkuBd7wzU KFiUmp5akZaZU4KQZuLgBBnOAzT8LkgNb3FBYm5xZjpE/hSjopQ47xGQhABIIqM0D64XlnZe MYoDvSLM+wCkigeYsuC6XwENZgIanMDXDjK4JBEhJdXAqFO0Ksla+vYF3pTr7T3zU1RZGNPa H/9e2LbQ6I0IC3u3E0NAiVycu8ixz8vL2rtD9V6tZY94WDvjTKdkqlmoq5PtVbOOL0/+P76Y M+tfMfvxzQK2k1JW2sjtaN28U+zyxyObipt+lC/OOtdgfcZl2c1FU9iszzYaCzeGbOo+0M/U 8cwn6uB9JZbijERDLeai4kQAuSbiJhYDAAA= Cc: " " Subject: Re: [kitten] Options for IAKERB compatibility issue X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 18:16:27 -0000 On 05/07/2013 02:02 PM, Love Hörnquist Åstrand wrote: > 2 is not an option, its 5 or 1. prefer 1. doubtless after doing interop > testing we'll find more issues. Can you please explain your objection to #3? From lha@kth.se Tue May 7 11:23:41 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38D3721F919A for ; Tue, 7 May 2013 11:23:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.948 X-Spam-Level: X-Spam-Status: No, score=-5.948 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iv8fAQeo5C7F for ; Tue, 7 May 2013 11:23:33 -0700 (PDT) Received: from smtp-2.sys.kth.se (smtp-2.sys.kth.se [130.237.32.160]) by ietfa.amsl.com (Postfix) with ESMTP id AEDD521F8F28 for ; Tue, 7 May 2013 11:23:32 -0700 (PDT) Received: from mailscan-1.sys.kth.se (mailscan-1.sys.kth.se [130.237.32.91]) by smtp-2.sys.kth.se (Postfix) with ESMTP id E9C0114DCB1; Tue, 7 May 2013 20:23:00 +0200 (CEST) X-Virus-Scanned: by amavisd-new at kth.se Received: from smtp-2.sys.kth.se ([130.237.32.160]) by mailscan-1.sys.kth.se (mailscan-1.sys.kth.se [130.237.32.91]) (amavisd-new, port 10024) with LMTP id kwOqGYqmkImD; Tue, 7 May 2013 20:22:56 +0200 (CEST) X-KTH-Auth: lha [17.212.162.217] X-KTH-mail-from: lha@kth.se Received: from [17.212.162.217] (unknown [17.212.162.217]) by smtp-2.sys.kth.se (Postfix) with ESMTP id 0177814DCA8; Tue, 7 May 2013 20:22:51 +0200 (CEST) Content-Type: multipart/alternative; boundary="Apple-Mail=_183C4934-3CDB-48A3-8588-F5715F30E53A" Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1750\)) From: =?iso-8859-1?Q?Love_H=F6rnquist_=C5strand?= In-Reply-To: <518944F0.8050504@mit.edu> Date: Tue, 7 May 2013 11:22:47 -0700 Message-Id: <93ED5FE4-9DAB-40F5-81FE-3AFF54F0C536@kth.se> References: <4969FAFD-094B-4774-B3B9-9B611FBF821A@kth.se> <518944F0.8050504@mit.edu> To: Greg Hudson X-Mailer: Apple Mail (2.1750) Cc: kitten@ietf.org Subject: Re: [kitten] Options for IAKERB compatibility issue X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 18:23:41 -0000 --Apple-Mail=_183C4934-3CDB-48A3-8588-F5715F30E53A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 7 maj 2013 kl. 11:16 skrev Greg Hudson : > On 05/07/2013 02:02 PM, Love H=F6rnquist =C5strand wrote: >> 2 is not an option, its 5 or 1. prefer 1. doubtless after doing = interop >> testing we'll find more issues. >=20 > Can you please explain your objection to #3? it require changes. I fine with saying REQUIRE framing, but if you want = to interop, you better consider accept unframed too. Love --Apple-Mail=_183C4934-3CDB-48A3-8588-F5715F30E53A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
7 maj 2013 kl. 11:16 skrev Greg Hudson = <ghudson@MIT.EDU>:

On 05/07/2013 = 02:02 PM, Love H=F6rnquist =C5strand wrote:
2= is not an option, its 5 or 1. prefer 1. doubtless after doing = interop
testing we'll find more issues.

Can you = please explain your objection to #3?

it = require changes. I fine with saying REQUIRE framing, but if you want to = interop, you better consider accept unframed = too.

Love

= --Apple-Mail=_183C4934-3CDB-48A3-8588-F5715F30E53A-- From ghudson@mit.edu Tue May 7 11:38:38 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A1F821F908B for ; Tue, 7 May 2013 11:38:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.524 X-Spam-Level: X-Spam-Status: No, score=-3.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AVgY2zE6XKf7 for ; Tue, 7 May 2013 11:38:31 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (DMZ-MAILSEC-SCANNER-4.MIT.EDU [18.9.25.15]) by ietfa.amsl.com (Postfix) with ESMTP id 7037721F8C1A for ; Tue, 7 May 2013 11:38:31 -0700 (PDT) X-AuditID: 1209190f-b7f256d000005616-d0-51894a267283 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 66.57.22038.62A49815; Tue, 7 May 2013 14:38:30 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id r47IcTmJ031424 for ; Tue, 7 May 2013 14:38:30 -0400 Received: from [18.189.54.192] ([18.189.54.192]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id r47IcSRN008906 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 7 May 2013 14:38:29 -0400 Message-ID: <51894A24.7000507@mit.edu> Date: Tue, 07 May 2013 14:38:28 -0400 From: Greg Hudson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130404 Thunderbird/17.0.5 MIME-Version: 1.0 To: kitten@ietf.org References: <4969FAFD-094B-4774-B3B9-9B611FBF821A@kth.se> <518944F0.8050504@mit.edu> In-Reply-To: <518944F0.8050504@mit.edu> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDIsWRmVeSWpSXmKPExsUixG6noqvm1RlosKtPyuLo5lUsDoweS5b8 ZApgjOKySUnNySxLLdK3S+DKmHVzCUvBOo6Knr2/2RsYb7J1MXJySAiYSLx/t50VwhaTuHBv PVhcSGAfo8TM9SpdjFxA9jFGiUvHtrJCOIeYJKa8f8cCUsUroCbxr30XM4jNIqAqsW0TxCQ2 AWWJg2e/gdWICoRInP7cxAxRLyhxcuYTsLiIgLDE7q3vgOIcHMICNhIfpiRCLK6SOH6wnQkk zCmgLnHsZyTEbZISi6Z1gnUyC+hIvOt7wAxhy0tsfzuHeQKj4CwkC2YhKZuFpGwBI/MqRtmU 3Crd3MTMnOLUZN3i5MS8vNQiXRO93MwSvdSU0k2MoEDllOTfwfjtoNIhRgEORiUe3gccnYFC rIllxZW5hxglOZiURHnT3IFCfEn5KZUZicUZ8UWlOanFhxglOJiVRHiFFIByvCmJlVWpRfkw KWkOFiVx3qspN/2FBNITS1KzU1MLUotgsjIcHEoSvBKeQI2CRanpqRVpmTklCGkmDk6Q4TxA w8U9QIYXFyTmFmemQ+RPMSpKifPKgTQLgCQySvPgemGJ5BWjONArwry8IFU8wCQE1/0KaDAT 0OAEvnaQwSWJCCmpBsbUdfaVdakXgfF8tNJY7MHyuufmd2quLTD5kezLaLviYMnHn+XPbjb1 bv354jhXYWBCifSj6z8kztZotLwPiD5XqeSYe3zSn1Ps9lecXAN/NDduFJPq6b0TdU7n5Dx1 9zdfDj6V/el05AevwrtjdXw+t/t5a40O9UWWX5STNrx+dY3Hw4MREUosxRmJhlrMRcWJABOo 6Of/AgAA Subject: Re: [kitten] Options for IAKERB compatibility issue X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 18:38:38 -0000 I just realized that we can use the absence of framing to detect an MIT IAKERB implementation. This makes the problem much more tractable. So here is option 6 (a variation of option 1), which is my preferred option: 6. The main text of the standard stays as-is. We add an appendix describing how to be compatible with the current MIT implementation: - Process messages without framing after the first initiator token. - If you're the initiator and you see an unframed acceptor token, use the MIT variant of the finished extension in the AP-REQ checksum (extension type 1 and key usage 42). - If you're the acceptor, process either variant of the finished extension. If we go in this direction, the MIT implementation can change to generate framing on all tokens, send the standard variant of the finished extension in the AP-REQ checksum if it sees a framed acceptor token, and process either variant of the finished extension in the acceptor. Sorry I didn't realize this yesterday; I could have cut out a substantial amount of noise. From hartmans@mit.edu Wed May 8 08:47:40 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 411BC21F8D00 for ; Wed, 8 May 2013 08:47:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4VMSf-ZNdUEl for ; Wed, 8 May 2013 08:47:34 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id DFE6021F8EBD for ; Wed, 8 May 2013 08:47:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id C921820488; Wed, 8 May 2013 11:45:05 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vfqAjRE1uyNU; Wed, 8 May 2013 11:45:05 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Wed, 8 May 2013 11:45:05 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 1EF774499; Wed, 8 May 2013 11:47:30 -0400 (EDT) From: Sam Hartman To: Greg Hudson References: <4969FAFD-094B-4774-B3B9-9B611FBF821A@kth.se> <518944F0.8050504@mit.edu> <51894A24.7000507@mit.edu> Date: Wed, 08 May 2013 11:47:30 -0400 In-Reply-To: <51894A24.7000507@mit.edu> (Greg Hudson's message of "Tue, 07 May 2013 14:38:28 -0400") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: kitten@ietf.org Subject: Re: [kitten] Options for IAKERB compatibility issue X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2013 15:47:41 -0000 Greg, presumably MIt would need to send unframed messages if it gets an unframed acceptor message as well. That is, I think your option works but your description of the appendix is incomplete. From ghudson@mit.edu Wed May 8 08:52:55 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3FAC21F9467 for ; Wed, 8 May 2013 08:52:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a3Dp16h4-zCo for ; Wed, 8 May 2013 08:52:48 -0700 (PDT) Received: from dmz-mailsec-scanner-5.mit.edu (DMZ-MAILSEC-SCANNER-5.MIT.EDU [18.7.68.34]) by ietfa.amsl.com (Postfix) with ESMTP id 52F1621F90AC for ; Wed, 8 May 2013 08:52:48 -0700 (PDT) X-AuditID: 12074422-b7f5b6d00000095d-6f-518a74cadefd Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id E8.04.02397.AC47A815; Wed, 8 May 2013 11:52:42 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id r48FqfOb018674; Wed, 8 May 2013 11:52:41 -0400 Received: from [18.101.8.202] (VPN-18-101-8-202.MIT.EDU [18.101.8.202]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id r48FqdY3018553 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 8 May 2013 11:52:40 -0400 Message-ID: <518A74C7.1060504@mit.edu> Date: Wed, 08 May 2013 11:52:39 -0400 From: Greg Hudson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130404 Thunderbird/17.0.5 MIME-Version: 1.0 To: Sam Hartman References: <4969FAFD-094B-4774-B3B9-9B611FBF821A@kth.se> <518944F0.8050504@mit.edu> <51894A24.7000507@mit.edu> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplleLIzCtJLcpLzFFi42IR4hRV1j1V0hVocGy2gMXXtgdsFkc3r2Jx YPJYsuQnk8fKqafZA5iiuGxSUnMyy1KL9O0SuDI2ty5mLljJVDFp222WBsZPjF2MnBwSAiYS vxfPZoewxSQu3FvP1sXIxSEksI9R4sXza8wQzgZGibUntjFBOIeZJFbPn8UE0sIroCbxffcO sFEsAqoSFxshxrIJKEscPPuNBcQWFQiROP25iRmiXlDi5MwnYHERASWJG4f/g9UzCwhLXNi+ l7WLkYNDWMBG4sOURIhd6xklFiy7CNbLCbRr8/1TrBCnSkosmtbJAtGrI/Gu7wEzhC0vsf3t HOYJjEKzkKybhaRsFpKyBYzMqxhlU3KrdHMTM3OKU5N1i5MT8/JSi3RN9XIzS/RSU0o3MYJC m91FaQfjz4NKhxgFOBiVeHgzErsChVgTy4orcw8xSnIwKYny6ucDhfiS8lMqMxKLM+KLSnNS iw8xSnAwK4nw3ksByvGmJFZWpRblw6SkOViUxHmvpdz0FxJITyxJzU5NLUgtgsnKcHAoSfBW FQM1ChalpqdWpGXmlCCkmTg4QYbzAA1vBKnhLS5IzC3OTIfIn2JUlBLnnQmSEABJZJTmwfXC Us8rRnGgV4R5O0GqeIBpC677FdBgJqDBCXztIINLEhFSUg2M/gtfHRPK/PZYRZ5H6YdJ8cW/ r7UUrPx26KQwbtp6y2ziCaZDfwWefbXdc/DjbKuP+TZN+dmaYZ7fj8/ufbpAWidN9PAxpo+u nr4bwjbuO1vi99mdM+DiRpuVxqptJ1WND75wnMX+cO90m0DnN14v/nswHDIoX5RXduJB+5Pv PIFez1WfGhv8V2Ipzkg01GIuKk4EAID/uSUYAwAA Cc: kitten@ietf.org Subject: Re: [kitten] Options for IAKERB compatibility issue X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2013 15:52:55 -0000 On 05/08/2013 11:47 AM, Sam Hartman wrote: > Greg, presumably MIt would need to send unframed messages if it gets an > unframed acceptor message as well. No, this is unnecessary. Our implementation will happily process framed messages for all context tokens. (Verified experimentally.) From hartmans@mit.edu Fri May 10 09:45:16 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7467C21F8ECA for ; Fri, 10 May 2013 09:45:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q6kHl6KB2dIz for ; Fri, 10 May 2013 09:45:11 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 18B3121F8F53 for ; Fri, 10 May 2013 09:45:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 67B6A20120 for ; Fri, 10 May 2013 12:42:35 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CtvkftlN8TjN for ; Fri, 10 May 2013 12:42:35 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (unknown [10.1.10.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS for ; Fri, 10 May 2013 12:42:35 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 433394499; Fri, 10 May 2013 12:45:06 -0400 (EDT) From: Sam Hartman To: kitten@ietf.org Date: Fri, 10 May 2013 12:45:06 -0400 Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [kitten] Berlin Meeting: Agenda Items and Attendance X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 16:45:16 -0000 Hi. the chairs would like to gage how much time we'll need in Berlin. We're wondering who will be able to attend and what agenda topics people would like to cover. Topics we expect to cover include: 1) GS2 updates (assuming principals are present) 2) Channel bound flag (assuming principals present) 3) Any updates to oauth, openid, saml and saml (again assuming we have the right folks) 4) IANA documents --Sam From internet-drafts@ietf.org Mon May 13 20:17:45 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3D2A21F8E9D; Mon, 13 May 2013 20:17:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.407 X-Spam-Level: X-Spam-Status: No, score=-102.407 tagged_above=-999 required=5 tests=[AWL=0.193, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5mSu8ghvGHTq; Mon, 13 May 2013 20:17:43 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 63B0C21F8E4E; Mon, 13 May 2013 20:17:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.44.p7 Message-ID: <20130514031743.25459.46009.idtracker@ietfa.amsl.com> Date: Mon, 13 May 2013 20:17:43 -0700 Cc: kitten@ietf.org Subject: [kitten] I-D Action: draft-ietf-kitten-sasl-saml-ec-09.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 May 2013 03:17:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Common Authentication Technology Next Gen= eration Working Group of the IETF. Title : SAML Enhanced Client SASL and GSS-API Mechanisms Author(s) : Scott Cantor Simon Josefsson Filename : draft-ietf-kitten-sasl-saml-ec-09.txt Pages : 38 Date : 2013-05-13 Abstract: Security Assertion Markup Language (SAML) 2.0 is a generalized framework for the exchange of security-related information between asserting and relying parties. Simple Authentication and Security Layer (SASL) and the Generic Security Service Application Program Interface (GSS-API) are application frameworks to facilitate an extensible authentication model. This document specifies a SASL and GSS-API mechanism for SAML 2.0 that leverages the capabilities of a SAML-aware "enhanced client" to address significant barriers to federated authentication in a manner that encourages reuse of existing SAML bindings and profiles designed for non-browser scenarios. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-kitten-sasl-saml-ec There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-kitten-sasl-saml-ec-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-kitten-sasl-saml-ec-09 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From hartmans@mit.edu Tue May 14 12:45:44 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0537E21F898A for ; Tue, 14 May 2013 12:45:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DCnkQIgv+246 for ; Tue, 14 May 2013 12:45:38 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 813BA21F8532 for ; Tue, 14 May 2013 12:45:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id EAAFA2054D for ; Tue, 14 May 2013 15:42:54 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tSm1n78IvDK2 for ; Tue, 14 May 2013 15:42:54 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS for ; Tue, 14 May 2013 15:42:54 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 89E014499; Tue, 14 May 2013 15:45:34 -0400 (EDT) From: Sam Hartman To: kitten@ietf.org Date: Tue, 14 May 2013 15:45:34 -0400 Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [kitten] Comments on draft-ietf-kitten-aes-cts-hmac-sha2-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 May 2013 19:45:44 -0000 Overall: I think this is in fairly good shape. My comments seem to mostly fall into two categories: 1) As chair I'm requesting that this document make no reference to terminology or concepts introduced in the simplified profile in RFC 3961. For the most part I'd expect this spec to refer only to RFC 3961 sections 3 and 4. 2) I recommend that the editors minimize references to RFC 3962; in general repeating text from RFC 3962 is probably better than references. This is a recommendation, not a requirement for progression; if the editors consider the issue and believe that some references to RFC 3962 improve clarity or minimize the probability of specification or implementation error, I'll be happy with that. Detailed comments: section 4: The salt input to string_to_key is not under the control of a specification of an RFC 3961 enctype. It's inappropriate to place restrictions on the salt in this specification. Operationally what you may want is to encourage KDCs to include 128-bits of randomness in the salt they use. That doesn't belong as part of the encryption type specification; it may be appropriate in the same document, clearly separated. However, I think there are some issues related to keying services that tend to come up if the salt contains random data. I know the MIT folks explored this; I don't remember all the conclusions. If this property is important, you'll almost certainly want to explore advantages attackers could gain by causing a client to use the default Kerberos salt--that is, just the principal and realm. If we don't end up liking the implications of that analysis we'll need to look at changes broader in scope than are appropriate for an enctype specification. Section 5: You seem to be using the function dr(), defined as part of the simplified profile in RFC 3961, but your definition is different than that in RFC 3961. I find this notation confusing and would recommend against adopting notation from the simplified profile. Similarly, calling the key usage input to the key derivation n is notation from the simplified profile, not from section 3 of RFC 3961 and is highly confusing. section 6: The use of notation from the simplified profile is really problematic here. I think using cE, D and m is fine. I just think it would be desirable to define them yourself rather than referencing the simplified profile definitions. I think I'd like to hear responses to these comments before deciding whether we're ready for working group last call. From ghudson@mit.edu Tue May 14 16:00:37 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1406F21F84DC for ; Tue, 14 May 2013 16:00:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9yOg0aLO1aSh for ; Tue, 14 May 2013 16:00:30 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (DMZ-MAILSEC-SCANNER-2.MIT.EDU [18.9.25.13]) by ietfa.amsl.com (Postfix) with ESMTP id 6DF6A21F8488 for ; Tue, 14 May 2013 16:00:29 -0700 (PDT) X-AuditID: 1209190d-b7f716d000005557-08-5192c20c1c85 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id E0.93.21847.D02C2915; Tue, 14 May 2013 19:00:29 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id r4EN0SHW005212; Tue, 14 May 2013 19:00:28 -0400 Received: from [18.101.8.179] (VPN-18-101-8-179.MIT.EDU [18.101.8.179]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id r4EN0QKV023352 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 14 May 2013 19:00:27 -0400 Message-ID: <5192C20A.6040907@mit.edu> Date: Tue, 14 May 2013 19:00:26 -0400 From: Greg Hudson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130404 Thunderbird/17.0.5 MIME-Version: 1.0 To: Sam Hartman References: In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplleLIzCtJLcpLzFFi42IRYrdT0eU9NCnQYOcvZouvbQ/YLI5uXsXi wOSxZMlPJo+VU0+zBzBFcdmkpOZklqUW6dslcGVMurGfreAdc8Wmq6cYGxjbmLsYOTkkBEwk Hl58zQhhi0lcuLeerYuRi0NIYB+jxKY5l1ggnI2MEjNnTGKEcI4wSdz9cx+shVdATeL+o7fs IDaLgKrEr4Pf2EBsNgFliYNnv7GA2KICIRKnPzcxQ9QLSpyc+QQsLiKgLrH60iSwXmYBYYkL 2/eygtjCAh4SD1c+A5sjBDTz9dwbYDWcQLt+PWhggzhVUmLRtE4WiF4diXd9D5ghbHmJ7W/n ME9gFJqFZN0sJGWzkJQtYGRexSibklulm5uYmVOcmqxbnJyYl5dapGukl5tZopeaUrqJERTa nJK8OxjfHVQ6xCjAwajEwyvhPylQiDWxrLgy9xCjJAeTkiiv/QqgEF9SfkplRmJxRnxRaU5q 8SFGCQ5mJRHe51FAOd6UxMqq1KJ8mJQ0B4uSOO+VlJv+QgLpiSWp2ampBalFMFkZDg4lCd6l B4AaBYtS01Mr0jJzShDSTBycIMN5gIbvBanhLS5IzC3OTIfIn2JUlBLnPQCSEABJZJTmwfXC Us8rRnGgV4R5d4NU8QDTFlz3K6DBTECDNUvABpckIqSkGhij9W/FVB6SVohbl7O6d0XvvgfH Dstqaic67mcIaovbXR18Xu5OjnJdC2dT2Optn1L2PK0+///Kw9Ysp+7SeU0J8ZoHfqmdUbCe 57DxWH4Y22oh6+AP69W35xw5Xjqr/ZPX03dexeWrjaXWHp6scOuk8/3tVbfMG7hbj61/I8ht Zlhy7+qriQJKLMUZiYZazEXFiQBp6TbkGAMAAA== Cc: kitten@ietf.org Subject: Re: [kitten] Comments on draft-ietf-kitten-aes-cts-hmac-sha2-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 May 2013 23:00:37 -0000 I have an additional comment: Section 6 notes that "[SP800-38A+] requires the plaintext length to be greater than or equal to the block size" but gives no guidance on what to do if the input is smaller than that. This seems like a pretty serious problem. The RFC 3962 enctypes do not have this problem because they use a confounder, which adds a block of input. They did have to specify what to do when the input length is 0, such that the cipher plaintext is exactly one block. From hartmans@mit.edu Tue May 14 16:32:31 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 627F421F8A74 for ; Tue, 14 May 2013 16:32:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CFkOcQLyuBa0 for ; Tue, 14 May 2013 16:32:25 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 8112321F85ED for ; Tue, 14 May 2013 16:32:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id AA1792057B; Tue, 14 May 2013 19:29:42 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CEWTpCksmd5Z; Tue, 14 May 2013 19:29:42 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Tue, 14 May 2013 19:29:42 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id D9F614499; Tue, 14 May 2013 19:32:22 -0400 (EDT) From: Sam Hartman To: Greg Hudson References: <5192C20A.6040907@mit.edu> Date: Tue, 14 May 2013 19:32:22 -0400 In-Reply-To: <5192C20A.6040907@mit.edu> (Greg Hudson's message of "Tue, 14 May 2013 19:00:26 -0400") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: kitten@ietf.org, Sam Hartman Subject: Re: [kitten] Comments on draft-ietf-kitten-aes-cts-hmac-sha2-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 May 2013 23:32:31 -0000 >>>>> "Greg" == Greg Hudson writes: Greg> I have an additional comment: Section 6 notes that Greg> "[SP800-38A+] requires the plaintext length to be greater than Greg> or equal to the block size" but gives no guidance on what to Greg> do if the input is smaller than that. This seems like a Greg> pretty serious problem. Greg> The RFC 3962 enctypes do not have this problem because they Greg> use a confounder, which adds a block of input. They did have Greg> to specify what to do when the input length is 0, such that Greg> the cipher plaintext is exactly one block. Thanks. Yeah, I had missed this item because I was thinking there would be a confounder, but that's not how the nonce is handled. From shawn.emery@oracle.com Wed May 15 00:28:40 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2BDB21F8D7A for ; Wed, 15 May 2013 00:28:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.299 X-Spam-Level: X-Spam-Status: No, score=-5.299 tagged_above=-999 required=5 tests=[AWL=1.299, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dc69ytaLyaYB for ; Wed, 15 May 2013 00:28:34 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 367AA21F8D31 for ; Wed, 15 May 2013 00:28:34 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r4F7SVp7006475 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 15 May 2013 07:28:32 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4F7SWBF009139 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 15 May 2013 07:28:32 GMT Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4F7SVnq016128 for ; Wed, 15 May 2013 07:28:31 GMT Received: from [10.159.109.119] (/10.159.109.119) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 15 May 2013 00:28:31 -0700 Message-ID: <519338F5.3030006@oracle.com> Date: Wed, 15 May 2013 01:27:49 -0600 From: Shawn Emery User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "kitten@ietf.org" References: <51927692.1090007@oracle.com> In-Reply-To: <51927692.1090007@oracle.com> X-Forwarded-Message-Id: <51927692.1090007@oracle.com> Content-Type: multipart/alternative; boundary="------------090104010106040304090708" X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Subject: [kitten] Consensus Calls X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2013 07:28:41 -0000 This is a multi-part message in MIME format. --------------090104010106040304090708 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit The WG is making the following consensus calls (which were formulated from the interim meeting held on May 6th): 1. In regards to draft-ietf-kitten-sasl-oauth,RFC 6616, and RFC 6595;do we allow for GS2 mechanisms that don't providemutual authentication? This would entail changing the GS2 specification (RFC 5801) to relax this constraint. a. Yes b. No c. Don't careor need more information 2. Do we allow the IAKERB draft (draft-ietf-kitten-iakerb) to pull in the finished message text from the PKU2U draft (draft-zhu-pku2u)? Subsequently, if the PKU2U draftis progressed, it will make a normative reference to the IAKERB draft. a. Yes b. No c. Don't careor need more information 3. In regards todraft-williams-kitten-channel-bound-flag; are you in favor of using the NULL contextsolution for the channel bound indicatoras opposed to a new set credential API? a. Yes b. No c. Don't careor need more information Please provide your input before May 29th.Thank you. Shawn Emery. kitten co-chair -- --------------090104010106040304090708 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
The WG is making the following consensus calls (which were formulated from the interim meeting held on May 6th):

1. In regards to draft-ietf-kitten-sasl-oauth, RFC 6616, and RFC 6595; do we allow for GS2 mechanisms that don't provide mutual authentication?  This would entail changing the GS2 specification (RFC 5801) to relax this constraint.

a. Yes
b. No
c. Don't care or need more information
 
2. Do we allow the IAKERB draft (draft-ietf-kitten-iakerb) to pull in the finished message text from the PKU2U draft (draft-zhu-pku2u)?  Subsequently, if the PKU2U draft is progressed, it will make a normative reference to the IAKERB draft.

a. Yes
b. No
c. Don't care or need more information

3. In regards to draft-williams-kitten-channel-bound-flag; are you in favor of using the NULL context solution for the channel bound indicator as opposed to a new set credential API?

a. Yes
b. No
c. Don't care or need more information

Please provide your input before May 29th.  Thank you.

 Shawn Emery.
kitten co-chair
--
--------------090104010106040304090708-- From kwburgi@tycho.ncsc.mil Thu May 16 08:12:29 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D52DF21F91CB for ; Thu, 16 May 2013 08:12:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DiEBSJGjC--7 for ; Thu, 16 May 2013 08:12:24 -0700 (PDT) Received: from nsa.gov (emvm-gh1-uea08.nsa.gov [63.239.67.9]) by ietfa.amsl.com (Postfix) with ESMTP id C1B9421F918C for ; Thu, 16 May 2013 08:12:23 -0700 (PDT) X-TM-IMSS-Message-ID: <311d84bf000588f2@nsa.gov> Received: from tarius.tycho.ncsc.mil ([144.51.31.2]) by nsa.gov ([63.239.67.9]) with ESMTP (TREND IMSS SMTP Service 7.1) id 311d84bf000588f2 ; Thu, 16 May 2013 11:10:51 -0400 Received: from rd6um-58422h.infosec.tycho.ncsc.mil (rd6um-58422h [192.168.26.151]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id r4GFCGeM031205; Thu, 16 May 2013 11:12:16 -0400 Message-Id: <44302EA3-1CB6-4F9A-A6B4-25F5FCDBCC0A@tycho.ncsc.mil> From: Kelley Burgin To: kitten@ietf.org In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 16 May 2013 11:15:53 -0400 References: X-Mailer: Apple Mail (2.936) Cc: Sam Hartman Subject: Re: [kitten] Comments on draft-ietf-kitten-aes-cts-hmac-sha2-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2013 15:12:29 -0000 Thanks for your comments, my responses inline below. Basically, I'm happy to make the requested changes and have some proposed solutions for when the plaintext length is less than the blocksize. Kelley > I think this is in fairly good shape. My comments seem to mostly fall > into two categories: > > 1) As chair I'm requesting that this document make no reference to > terminology or concepts introduced in the simplified profile in RFC > 3961. > For the most part I'd expect this spec to refer only to RFC 3961 > sections 3 and 4. > [kwb] No problem. > 2) I recommend that the editors minimize references to RFC 3962; in > general repeating text from RFC 3962 is probably better than > references. > This is a recommendation, not a requirement for progression; if the > editors consider the issue and believe that some references to RFC > 3962 > improve clarity or minimize the probability of specification or > implementation error, I'll be happy with that. > [kwb] No problem. > > The salt input to string_to_key is not under the control of a > specification of an RFC 3961 enctype. > It's inappropriate to place restrictions on the salt in this > specification. > Operationally what you may want is to encourage KDCs to include 128- > bits > of randomness in the salt they use. > That doesn't belong as part of the encryption type specification; it > may > be appropriate in the same document, clearly separated. > > However, I think there are some issues related to keying services that > tend to come up if the salt contains random data. I know the MIT folks > explored this; I don't remember all the conclusions. > > If this property is important, you'll almost certainly want to explore > advantages attackers could gain by causing a client to use the default > Kerberos salt--that is, just the principal and realm. If we don't end > up liking the implications of that analysis we'll need to look at > changes broader in scope than are appropriate for an enctype > specification. > [kwb] Are you ok with "SHOULD include 128-bits of random"? > > Section 5: > > > You seem to be using the function dr(), defined as part of the > simplified profile in RFC 3961, but your definition is different than > that in RFC 3961. I find this notation confusing and would recommend > against adopting notation from the simplified profile. > > Similarly, calling the key usage input to the key derivation n is > notation from the simplified profile, not from section 3 of RFC 3961 > and > is highly confusing. > [kwb] I'll change this. > > section 6: > > The use of notation from the simplified profile is really problematic > here. > > I think using cE, D and m is fine. I just think it would be > desirable to > define them yourself rather than referencing the simplified profile > definitions. > > I think I'd like to hear responses to these comments before deciding > whether we're ready for working group last call. > > > ------------------------------ > > Date: Tue, 14 May 2013 19:00:26 -0400 > From: Greg Hudson > To: Sam Hartman > Cc: kitten@ietf.org > Subject: Re: [kitten] Comments on > draft-ietf-kitten-aes-cts-hmac-sha2-00 > Message-ID: <5192C20A.6040907@mit.edu> > Content-Type: text/plain; charset=ISO-8859-1 > > I have an additional comment: > > Section 6 notes that "[SP800-38A+] requires the plaintext length to be > greater than or equal to the block size" but gives no guidance on what > to do if the input is smaller than that. This seems like a pretty > serious problem. [kwb] CTS won't work, so two work arounds are: 1. Pad the plaintext to a block length, but this brings back issues with the ciphertext length being greater than plaintext length. 2. Use a different mode, counter mode for example (only in this special case). Encrypt the IV and xor the result with the plaintext (padded with zeros). Output the appropriate partial ciphertext so there's no expansion. From hartmans@mit.edu Thu May 16 08:27:27 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22BD121F8FF8 for ; Thu, 16 May 2013 08:27:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h2B0LRm1h8J5 for ; Thu, 16 May 2013 08:27:17 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 1811321F87CD for ; Thu, 16 May 2013 08:27:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 6EE5B202BF; Thu, 16 May 2013 11:24:10 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bJucKdjcAH2N; Thu, 16 May 2013 11:24:09 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (unknown [10.1.10.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Thu, 16 May 2013 11:24:09 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 8F6B6440A; Thu, 16 May 2013 11:26:54 -0400 (EDT) From: Sam Hartman To: Kelley Burgin References: <44302EA3-1CB6-4F9A-A6B4-25F5FCDBCC0A@tycho.ncsc.mil> Date: Thu, 16 May 2013 11:26:54 -0400 In-Reply-To: <44302EA3-1CB6-4F9A-A6B4-25F5FCDBCC0A@tycho.ncsc.mil> (Kelley Burgin's message of "Thu, 16 May 2013 11:15:53 -0400") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: kitten@ietf.org, Sam Hartman Subject: Re: [kitten] Comments on draft-ietf-kitten-aes-cts-hmac-sha2-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2013 15:27:27 -0000 >>>>> "Kelley" == Kelley Burgin writes: Kelley> [kwb] Are you ok with "SHOULD include 128-bits of random"? Not really. That feels like ignoring an important issue. The point you bring up about salt seems significant and I think deserves more than a sentence, especially a SHOULD without qualifications. I'd like to first understand from Greg or Ken or whoever looked at random salts at MIT what the complexities are. Then I'd like to better understand how you want this requirement enforced and what attacks you are worried about. At that point I think we can propose some text for a new section. -------------------- I'd like to ask the WG whether we think the less-than-a-block issue is a practical problem or whether it's just a completeness issue. If we don't expect either GSS-API or Kerberos messages to generate inputs less than a block, then I think having "trailing crypto garbage," (ciphertext length greater than plaintext length) in that one case might be fine. Thoughts? From ghudson@mit.edu Thu May 16 09:36:54 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B33AB11E8103 for ; Thu, 16 May 2013 09:36:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u9Fnr7itZZym for ; Thu, 16 May 2013 09:36:40 -0700 (PDT) Received: from dmz-mailsec-scanner-1.mit.edu (DMZ-MAILSEC-SCANNER-1.MIT.EDU [18.9.25.12]) by ietfa.amsl.com (Postfix) with ESMTP id 8E77D21F898A for ; Thu, 16 May 2013 09:36:40 -0700 (PDT) X-AuditID: 1209190c-b7f566d000004c69-c3-51950b17166e Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id DE.EB.19561.71B05915; Thu, 16 May 2013 12:36:39 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id r4GGacQP025655; Thu, 16 May 2013 12:36:39 -0400 Received: from [18.101.8.95] (VPN-18-101-8-95.MIT.EDU [18.101.8.95]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id r4GGaZlv009160 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 16 May 2013 12:36:37 -0400 Message-ID: <51950B13.3090508@mit.edu> Date: Thu, 16 May 2013 12:36:35 -0400 From: Greg Hudson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130404 Thunderbird/17.0.5 MIME-Version: 1.0 To: Sam Hartman References: <44302EA3-1CB6-4F9A-A6B4-25F5FCDBCC0A@tycho.ncsc.mil> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupileLIzCtJLcpLzFFi42IRYrdT0RXnnhpo8HeOnsXXtgdsFkc3r2Kx mNeQ4cDssWTJTyaPlVNPs3tsbf7HGMAcxWWTkpqTWZZapG+XwJUx43BgwT/hirdHEhoYf/B3 MXJySAiYSHzacoIZwhaTuHBvPVsXIxeHkMA+RomFPduYIZyNjBJvVjSCVQkJHGSS+HJCtouR g4NXQE1izfIckDCLgKrElwXfmUBsNgFliYNnv7GA2KICIRKnPzeBtfIKCEqcnPkELC4ioC6x +tIkdpAxzALWEq3/00HCwgIeEg9XPoO6oZNRYtqld6wgCU6gVZd/NUMdKimxaFon2BxmAR2J d30PmCFseYntb+cwT2AUmoVk3SwkZbOQlC1gZF7FKJuSW6Wbm5iZU5yarFucnJiXl1qka6iX m1mil5pSuokRFOSckjw7GN8cVDrEKMDBqMTDq/hzSqAQa2JZcWXuIUZJDiYlUd4mjqmBQnxJ +SmVGYnFGfFFpTmpxYcYJTiYlUR4y5mBcrwpiZVVqUX5MClpDhYlcd7LKTf9hQTSE0tSs1NT C1KLYLIyHBxKErxXOYEaBYtS01Mr0jJzShDSTBycIMN5gIafB6nhLS5IzC3OTIfIn2JUlBLn 3QOSEABJZJTmwfXCktArRnGgV4R5l4FU8QATGFz3K6DBTECDNUsmgQwuSURISTUwBj7atuaG 2O29ywPevRLfzPTx0GdpBzkF447JkZe6bA0Pc1ZXuR51S7E6LL2Q/972ulPfgrtvJh3+o5B3 4fvK48sKE+8n7Pgq3v2kvbzghOExtakLN93jqDMNfsGWeLX+7PvQj7OtJQ8JNEUwRL60DSv6 qye0RCxi3esJWaX3OUxuWNzR+SB7QImlOCPRUIu5qDgRAMhBJGgdAwAA Cc: kitten@ietf.org Subject: Re: [kitten] Comments on draft-ietf-kitten-aes-cts-hmac-sha2-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2013 16:36:54 -0000 On 05/16/2013 11:26 AM, Sam Hartman wrote: >>>>>> "Kelley" == Kelley Burgin writes: > Kelley> [kwb] Are you ok with "SHOULD include 128-bits of random"? > > Not really. That feels like ignoring an important issue. The point you > bring up about salt seems significant and I think deserves more than a > sentence, especially a SHOULD without qualifications. I agree with Sam here. An RFC 3961 enctype defines a (random) function, not a set of constraints on the inputs. This seems like fodder for the suiteb draft or something else. > I'd like to first understand from Greg or Ken or whoever looked at > random salts at MIT what the complexities are. Here's what I ran into when trying to make random salts the default in MIT krb5: * Password history checking stops working as we currently implement it in MIT krb5, and the obvious alternative makes changing passwords more computationally expensive for kadmind. * ktutil's add_entry command assumes the default salt. A similar problem applies when keying Windows services, if I understand how that normally works. * Cross-realm TGTs are currently managed by entering the same password at two KDCs to get the same keys. If each KDC uses a random salt, they won't have the same keys. All of these can be mitigated, but it adds up to a substantial project. We added support for random salts in 1.10, but not by default (and it only uses a non-configurable 64 random bits at the moment, but that's a simple change). > I'd like to ask the WG whether we think the less-than-a-block issue is a > practical problem or whether it's just a completeness issue. It would be a serious practical problem if an enctype implementation was expected to just fail on inputs less than 16 bytes. I don't know if it would be a practical problem to have ciphertext expansion for a small input. I suspect it wouldn't be a problem for MIT krb5 since we're used to it with DES and DES3 (although not with CFX in GSSAPI). I tried running our test suite with a 16-byte plaintext minimum to identify small messages, but it only got as far as encrypting key data during KDB setup. That's not a PDU so it's not terribly interesting. I'm interested in Kelley's idea of using CTR with the random IV as the counter. Obviously an IV collision would expose the XOR of the plaintexts of the colliding blocks, but I think that's no worse than CBC (a colliding cipher block exposes the XOR of the plaintexts of the preceding blocks, IIRC). From kwburgi@tycho.ncsc.mil Fri May 17 06:44:17 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50AD321F84F5 for ; Fri, 17 May 2013 06:44:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ypdjFT9qkhxY for ; Fri, 17 May 2013 06:44:11 -0700 (PDT) Received: from nsa.gov (emvm-gh1-uea09.nsa.gov [63.239.67.10]) by ietfa.amsl.com (Postfix) with ESMTP id CC17A21F85EF for ; Fri, 17 May 2013 06:44:10 -0700 (PDT) X-TM-IMSS-Message-ID: <122ac6cb00061354@nsa.gov> Received: from tarius.tycho.ncsc.mil ([144.51.31.2]) by nsa.gov ([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1) id 122ac6cb00061354 ; Fri, 17 May 2013 09:47:16 -0400 Received: from rd6um-58422h.infosec.tycho.ncsc.mil (rd6um-58422h [192.168.26.151]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id r4HDi522032688; Fri, 17 May 2013 09:44:05 -0400 Message-Id: From: Kelley Burgin To: Greg Hudson In-Reply-To: <51950B13.3090508@mit.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 17 May 2013 09:47:44 -0400 References: <44302EA3-1CB6-4F9A-A6B4-25F5FCDBCC0A@tycho.ncsc.mil> <51950B13.3090508@mit.edu> X-Mailer: Apple Mail (2.936) Cc: kitten@ietf.org, Sam Hartman Subject: Re: [kitten] Comments on draft-ietf-kitten-aes-cts-hmac-sha2-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 13:44:17 -0000 Even though I see value in adding random to the salt, I don't think it warrants taking on a substantial project. Any objections to taking out the requirement for random in the salt, and adding some text to the effect of "If NIST guidance to include 128 bits of random in the salt is followed, be aware of these issues..." Also make a note that the random would need to be passed to the client in some appropriate padata field? Kelley On May 16, 2013, at 12:36 PM, Greg Hudson wrote: > On 05/16/2013 11:26 AM, Sam Hartman wrote: >>>>>>> "Kelley" == Kelley Burgin writes: >> Kelley> [kwb] Are you ok with "SHOULD include 128-bits of random"? >> >> Not really. That feels like ignoring an important issue. The >> point you >> bring up about salt seems significant and I think deserves more >> than a >> sentence, especially a SHOULD without qualifications. > > I agree with Sam here. An RFC 3961 enctype defines a (random) > function, > not a set of constraints on the inputs. This seems like fodder for > the > suiteb draft or something else. > >> I'd like to first understand from Greg or Ken or whoever looked at >> random salts at MIT what the complexities are. > > Here's what I ran into when trying to make random salts the default in > MIT krb5: > > * Password history checking stops working as we currently implement it > in MIT krb5, and the obvious alternative makes changing passwords more > computationally expensive for kadmind. > > * ktutil's add_entry command assumes the default salt. A similar > problem applies when keying Windows services, if I understand how that > normally works. > > * Cross-realm TGTs are currently managed by entering the same password > at two KDCs to get the same keys. If each KDC uses a random salt, > they > won't have the same keys. > > All of these can be mitigated, but it adds up to a substantial > project. > We added support for random salts in 1.10, but not by default (and it > only uses a non-configurable 64 random bits at the moment, but > that's a > simple change). > >> I'd like to ask the WG whether we think the less-than-a-block issue >> is a >> practical problem or whether it's just a completeness issue. > > It would be a serious practical problem if an enctype implementation > was > expected to just fail on inputs less than 16 bytes. I don't know if > it > would be a practical problem to have ciphertext expansion for a small > input. I suspect it wouldn't be a problem for MIT krb5 since we're > used > to it with DES and DES3 (although not with CFX in GSSAPI). > > I tried running our test suite with a 16-byte plaintext minimum to > identify small messages, but it only got as far as encrypting key data > during KDB setup. That's not a PDU so it's not terribly interesting. > > I'm interested in Kelley's idea of using CTR with the random IV as the > counter. Obviously an IV collision would expose the XOR of the > plaintexts of the colliding blocks, but I think that's no worse than > CBC > (a colliding cipher block exposes the XOR of the plaintexts of the > preceding blocks, IIRC). > From ghudson@mit.edu Fri May 17 07:00:53 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B793821F933B for ; Fri, 17 May 2013 07:00:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id arAL4bmHBLEs for ; Fri, 17 May 2013 07:00:38 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (DMZ-MAILSEC-SCANNER-6.MIT.EDU [18.7.68.35]) by ietfa.amsl.com (Postfix) with ESMTP id 371B121F9301 for ; Fri, 17 May 2013 07:00:37 -0700 (PDT) X-AuditID: 12074423-b7f826d000001438-c8-51963804a60e Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id F9.8D.05176.40836915; Fri, 17 May 2013 10:00:36 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id r4HE0ZVA021662; Fri, 17 May 2013 10:00:35 -0400 Received: from [18.101.8.191] (VPN-18-101-8-191.MIT.EDU [18.101.8.191]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id r4HE0Wtv032012 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 17 May 2013 10:00:34 -0400 Message-ID: <51963800.3010204@mit.edu> Date: Fri, 17 May 2013 10:00:32 -0400 From: Greg Hudson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130404 Thunderbird/17.0.5 MIME-Version: 1.0 To: Kelley Burgin References: <44302EA3-1CB6-4F9A-A6B4-25F5FCDBCC0A@tycho.ncsc.mil> <51950B13.3090508@mit.edu> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBKsWRmVeSWpSXmKPExsUixG6nostiMS3Q4Pd2BYuvbQ/YLI5uXsVi Ma8hw+L0refMDiweS5b8ZPJ423CV3WPl1NPsHlub/zEGsERx2aSk5mSWpRbp2yVwZRyb85G9 YBN7xc0NT9gaGD+ydjFyckgImEh8PPiLBcIWk7hwbz1bFyMXh5DAPkaJ3/PaGCGcjYwSDx5M ZIVwjjBJnNywA6iFg4NXQE1ixslEkG4WAVWJtz+2sIPYbALKEgfPfgObKioQInH6cxMziM0r IChxcuYTsLiIgJbE1YdzwOLMAskSfVPXgdnCAh4SD1c+g7riFqPEh0mLmEASnAJOEu/nL2eD OFVSYtG0ThaIZh2Jd30PoAbJS2x/O4d5AqPQLCT7ZiEpm4WkbAEj8ypG2ZTcKt3cxMyc4tRk 3eLkxLy81CJdM73czBK91JTSTYzgCHBR3sH456DSIUYBDkYlHl6Fn1MChVgTy4orcw8xSnIw KYnyuhtMCxTiS8pPqcxILM6ILyrNSS0+xCjBwawkwnv849RAId6UxMqq1KJ8mJQ0B4uSOO+1 lJv+QgLpiSWp2ampBalFMFkZDg4lCd4VZkBDBYtS01Mr0jJzShDSTBycIMN5gIZvAanhLS5I zC3OTIfIn2JUlBLnrQFJCIAkMkrz4HphCeoVozjQK8K8zSBVPMDkBtf9CmgwE9Bg1msgVxeX JCKkpBoYZ6/LmnFnxfYlK402F9TyH+VyU9nS78LwxMDw567wuzVqUVfu3zI5b52b/SqQmWXe EvsDQQfajzqf4mv4eGfjpa86bFa3U9bGfZzl63axnOdR/kuOGj3tIJ7oUyuKg/hfVbllWLoH X447msNtumdre1h6SXQJ/zfBtce7HxkJ6b48HSa7t5NTiaU4I9FQi7moOBEABJpxGSsDAAA= Cc: kitten@ietf.org, Sam Hartman Subject: Re: [kitten] Comments on draft-ietf-kitten-aes-cts-hmac-sha2-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 14:00:53 -0000 On 05/17/2013 09:47 AM, Kelley Burgin wrote: > Even though I see value in adding random to the salt, I don't think it > warrants taking on a substantial project. Any objections to taking out > the requirement for random in the salt, and adding some text to the > effect of "If NIST guidance to include 128 bits of random in the salt is > followed, be aware of these issues..." Also make a note that the random > would need to be passed to the client in some appropriate padata field? I'm opposed to having any text in an encryption type specification about the contents of the salt. An enctype implementation accepts the salt as input from a higher layer; it does not choose what goes into the salt. An RFC can contain multiple things (an enctype spec and also some text about salts), but they should be clearly delineated, and I'm not sure what this RFC would need to say about salts which isn't already stated in RFC 4120. From hartmans@mit.edu Fri May 17 07:10:59 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6555421F8B64 for ; Fri, 17 May 2013 07:10:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6vbsSBV6uYf2 for ; Fri, 17 May 2013 07:10:53 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 0179721F93E8 for ; Fri, 17 May 2013 07:10:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id B730A201C9; Fri, 17 May 2013 10:08:03 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e7qDKbVvExEG; Fri, 17 May 2013 10:08:02 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Fri, 17 May 2013 10:08:02 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 34AE8440A; Fri, 17 May 2013 10:10:48 -0400 (EDT) From: Sam Hartman To: Kelley Burgin References: <44302EA3-1CB6-4F9A-A6B4-25F5FCDBCC0A@tycho.ncsc.mil> <51950B13.3090508@mit.edu> Date: Fri, 17 May 2013 10:10:48 -0400 In-Reply-To: (Kelley Burgin's message of "Fri, 17 May 2013 09:47:44 -0400") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: kitten@ietf.org, Sam Hartman Subject: Re: [kitten] Comments on draft-ietf-kitten-aes-cts-hmac-sha2-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 14:10:59 -0000 >>>>> "Kelley" == Kelley Burgin writes: Kelley> Even though I see value in adding random to the salt, I Kelley> don't think it warrants taking on a substantial project. Any Kelley> objections to taking out the requirement for random in the Kelley> salt, and adding some text to the effect of "If NIST Kelley> guidance to include 128 bits of random in the salt is Kelley> followed, be aware of these issues..." Also make a note that Kelley> the random would need to be passed to the client in some Kelley> appropriate padata field? it sounds like you and Greg might both be happy with a new section in this document discussing random salts, and pointing out the issues. Greg asks what there is to say beyond RFC 4120? I think the big thing would be to give advice on how to figure out the salt of a service or cross-realm key. If we can find guidance for how implementations should approach that would it be valuable to document that guidance here? From kwburgi@tycho.ncsc.mil Fri May 17 07:22:29 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C57E21F9416 for ; Fri, 17 May 2013 07:22:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Mjeu44cxLid for ; Fri, 17 May 2013 07:22:23 -0700 (PDT) Received: from nsa.gov (emvm-gh1-uea08.nsa.gov [63.239.67.9]) by ietfa.amsl.com (Postfix) with ESMTP id DEC2321F937B for ; Fri, 17 May 2013 07:22:16 -0700 (PDT) X-TM-IMSS-Message-ID: <3615fb21000699b5@nsa.gov> Received: from tarius.tycho.ncsc.mil ([144.51.31.2]) by nsa.gov ([63.239.67.9]) with ESMTP (TREND IMSS SMTP Service 7.1) id 3615fb21000699b5 ; Fri, 17 May 2013 10:20:43 -0400 Received: from rd6um-58422h.infosec.tycho.ncsc.mil (rd6um-58422h [192.168.26.151]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id r4HEMAZ4002794; Fri, 17 May 2013 10:22:10 -0400 Message-Id: <8CB8B53A-1423-45C8-9C1E-7B618B915805@tycho.ncsc.mil> From: Kelley Burgin To: Greg Hudson In-Reply-To: <51963800.3010204@mit.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 17 May 2013 10:25:49 -0400 References: <44302EA3-1CB6-4F9A-A6B4-25F5FCDBCC0A@tycho.ncsc.mil> <51950B13.3090508@mit.edu> <51963800.3010204@mit.edu> X-Mailer: Apple Mail (2.936) Cc: kitten@ietf.org, Sam Hartman Subject: Re: [kitten] Comments on draft-ietf-kitten-aes-cts-hmac-sha2-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 14:22:29 -0000 We do have text about prepending the enctype name to the salt, which I think is important (although I guess this is technically saltp but still used as the "salt" in PBKDF). Are you opposed to random in the salt in the test vectors? On May 17, 2013, at 10:00 AM, Greg Hudson wrote: > On 05/17/2013 09:47 AM, Kelley Burgin wrote: >> Even though I see value in adding random to the salt, I don't think >> it >> warrants taking on a substantial project. Any objections to taking >> out >> the requirement for random in the salt, and adding some text to the >> effect of "If NIST guidance to include 128 bits of random in the >> salt is >> followed, be aware of these issues..." Also make a note that the >> random >> would need to be passed to the client in some appropriate padata >> field? > > I'm opposed to having any text in an encryption type specification > about > the contents of the salt. An enctype implementation accepts the > salt as > input from a higher layer; it does not choose what goes into the salt. > > An RFC can contain multiple things (an enctype spec and also some text > about salts), but they should be clearly delineated, and I'm not sure > what this RFC would need to say about salts which isn't already stated > in RFC 4120. > From hartmans@mit.edu Fri May 17 07:27:41 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2637F21F8C00 for ; Fri, 17 May 2013 07:27:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ghi2Lr61gdvA for ; Fri, 17 May 2013 07:27:25 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 5C02721F942B for ; Fri, 17 May 2013 07:27:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id B03AA2057B; Fri, 17 May 2013 10:24:36 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pfIYf8BCAMmD; Fri, 17 May 2013 10:24:36 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Fri, 17 May 2013 10:24:36 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id DFA6C440A; Fri, 17 May 2013 10:27:21 -0400 (EDT) From: Sam Hartman To: Kelley Burgin References: <44302EA3-1CB6-4F9A-A6B4-25F5FCDBCC0A@tycho.ncsc.mil> <51950B13.3090508@mit.edu> <51963800.3010204@mit.edu> <8CB8B53A-1423-45C8-9C1E-7B618B915805@tycho.ncsc.mil> Date: Fri, 17 May 2013 10:27:21 -0400 In-Reply-To: <8CB8B53A-1423-45C8-9C1E-7B618B915805@tycho.ncsc.mil> (Kelley Burgin's message of "Fri, 17 May 2013 10:25:49 -0400") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: kitten@ietf.org, Sam Hartman Subject: Re: [kitten] Comments on draft-ietf-kitten-aes-cts-hmac-sha2-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 14:27:41 -0000 >>>>> "Kelley" == Kelley Burgin writes: Kelley> We do have text about prepending the enctype name to the Kelley> salt, which I think is important (although I guess this is Kelley> technically saltp but still used as the "salt" in Kelley> PBKDF). I think that the way prepending the enctype name to the salt is done is fine. it's entirely internal to the crypto system. Kelley> Are you opposed to random in the salt in the test Kelley> vectors? As an individual I think that's fine. From ghudson@mit.edu Fri May 17 07:29:29 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC4FB21F9452 for ; Fri, 17 May 2013 07:29:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZXUn5NwMrfqG for ; Fri, 17 May 2013 07:29:23 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (DMZ-MAILSEC-SCANNER-4.MIT.EDU [18.9.25.15]) by ietfa.amsl.com (Postfix) with ESMTP id D70A721F933B for ; Fri, 17 May 2013 07:29:16 -0700 (PDT) X-AuditID: 1209190f-b7f256d000005616-81-51963ebb1b17 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 73.72.22038.BBE36915; Fri, 17 May 2013 10:29:15 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id r4HETEVV009421; Fri, 17 May 2013 10:29:14 -0400 Received: from [18.101.8.191] (VPN-18-101-8-191.MIT.EDU [18.101.8.191]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id r4HETC9h013036 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 17 May 2013 10:29:13 -0400 Message-ID: <51963EB8.80202@mit.edu> Date: Fri, 17 May 2013 10:29:12 -0400 From: Greg Hudson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130404 Thunderbird/17.0.5 MIME-Version: 1.0 To: Kelley Burgin References: <44302EA3-1CB6-4F9A-A6B4-25F5FCDBCC0A@tycho.ncsc.mil> <51950B13.3090508@mit.edu> <51963800.3010204@mit.edu> <8CB8B53A-1423-45C8-9C1E-7B618B915805@tycho.ncsc.mil> In-Reply-To: <8CB8B53A-1423-45C8-9C1E-7B618B915805@tycho.ncsc.mil> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprGKsWRmVeSWpSXmKPExsUixCmqrLvbblqgwfcjUhZf2x6wWRzdvIrF Yl5DhsXpW8+ZHVg8liz5yeTxtuEqu8fKqafZPbY2/2MMYInisklJzcksSy3St0vgyrhxqKbg L2vFoW6lBsa7LF2MnBwSAiYSvx6tYIOwxSQu3FsPZHNxCAnsY5S417+QESQhJLCRUeLoTkeI xBEmiX0PzrODJHgFVCSa1q8Cs1kEVCUOT5rGBGKzCShLHDz7DWyDqECIxOnPTcwQ9YISJ2c+ AYuLCGhJXH04ByzOLJAs0Td1HZgtLOAh8XDlM6grVjNJXPs6EWwBp4CTxPwDdxkhTpWUWDSt kwWiWUfiXd8DqEHyEtvfzmGewCg0C8m+WUjKZiEpW8DIvIpRNiW3Sjc3MTOnODVZtzg5MS8v tUjXRC83s0QvNaV0EyM4+CX5dzB+O6h0iFGAg1GJh1fh55RAIdbEsuLK3EOMkhxMSqK8/DbT AoX4kvJTKjMSizPii0pzUosPMUpwMCuJ8B7/ODVQiDclsbIqtSgfJiXNwaIkzns15aa/kEB6 YklqdmpqQWoRTFaGg0NJgtfeFmioYFFqempFWmZOCUKaiYMTZDgP0HAekBre4oLE3OLMdIj8 KUZFKXFeBZCEAEgiozQPrheWnF4xigO9IswrAlLFA0xscN2vgAYzAQ1mvQZydXFJIkJKqoFR w/yx/M2tSb1cHrvz9iiF/M5Tzp326eeu9FnLrvbtvbxl5f07n2sCVhxJ5Eqds3RpyomI9bNz BXa/sJzHvy9n9tUFEvyB5n/fnHT12x05O+XNkzRjFu3o1bP82d6ExcxSSX/9QeeLad+hxxf+ XeiebOkePeu9XfzFwq9Lbuxf35NrKbyjKviGixJLcUaioRZzUXEiAJoIYPApAwAA Cc: kitten@ietf.org, Sam Hartman Subject: Re: [kitten] Comments on draft-ietf-kitten-aes-cts-hmac-sha2-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 14:29:29 -0000 On 05/17/2013 10:25 AM, Kelley Burgin wrote: > We do have text about prepending the enctype name to the salt, which I > think is important (although I guess this is technically saltp but still > used as the "salt" in PBKDF). The distinction is important. The salt value arrives as an input from the RFC 4120 layer. What the enctype feeds into PBKDF2 is an internal detail of the enctype. (But an enctype cannot add random data to the input salt and feed that to PBKDF2, because string-to-key is not a random function.) > Are you opposed to random in the salt in the test vectors? Not at all. Programs which verify test vectors can feed in whatever salt is required. However, do note that RFC 3961 restricts salts to valid UTF-8 sequences. From kwburgi@tycho.ncsc.mil Fri May 17 09:36:18 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1F6921F9795 for ; Fri, 17 May 2013 09:36:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fdm696tN-Cjk for ; Fri, 17 May 2013 09:36:07 -0700 (PDT) Received: from nsa.gov (emvm-gh1-uea09.nsa.gov [63.239.67.10]) by ietfa.amsl.com (Postfix) with ESMTP id B1AB621F9739 for ; Fri, 17 May 2013 09:36:03 -0700 (PDT) X-TM-IMSS-Message-ID: <12c827f100064c4f@nsa.gov> Received: from tarius.tycho.ncsc.mil ([144.51.31.2]) by nsa.gov ([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1) id 12c827f100064c4f ; Fri, 17 May 2013 12:39:10 -0400 Received: from rd6um-58422h.infosec.tycho.ncsc.mil (rd6um-58422h [192.168.26.151]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id r4HGZxtE014779; Fri, 17 May 2013 12:35:59 -0400 Message-Id: From: Kelley Burgin To: Greg Hudson In-Reply-To: <51963EB8.80202@mit.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 17 May 2013 12:39:39 -0400 References: <44302EA3-1CB6-4F9A-A6B4-25F5FCDBCC0A@tycho.ncsc.mil> <51950B13.3090508@mit.edu> <51963800.3010204@mit.edu> <8CB8B53A-1423-45C8-9C1E-7B618B915805@tycho.ncsc.mil> <51963EB8.80202@mit.edu> X-Mailer: Apple Mail (2.936) Cc: kitten@ietf.org, Sam Hartman Subject: Re: [kitten] Comments on draft-ietf-kitten-aes-cts-hmac-sha2-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 16:36:18 -0000 To be clear, in response to Sam's earlier question, are you against a section discussing random salts which discusses cross realm issues? Thanks for reminding me about the UTF-8 restriction. On May 17, 2013, at 10:29 AM, Greg Hudson wrote: > On 05/17/2013 10:25 AM, Kelley Burgin wrote: >> We do have text about prepending the enctype name to the salt, >> which I >> think is important (although I guess this is technically saltp but >> still >> used as the "salt" in PBKDF). > > The distinction is important. The salt value arrives as an input from > the RFC 4120 layer. What the enctype feeds into PBKDF2 is an internal > detail of the enctype. (But an enctype cannot add random data to the > input salt and feed that to PBKDF2, because string-to-key is not a > random function.) > >> Are you opposed to random in the salt in the test vectors? > > Not at all. Programs which verify test vectors can feed in whatever > salt is required. However, do note that RFC 3961 restricts salts to > valid UTF-8 sequences. > From ghudson@mit.edu Fri May 17 09:52:18 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34B0421F977C for ; Fri, 17 May 2013 09:52:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nn4Kg9+bGv32 for ; Fri, 17 May 2013 09:52:10 -0700 (PDT) Received: from dmz-mailsec-scanner-5.mit.edu (DMZ-MAILSEC-SCANNER-5.MIT.EDU [18.7.68.34]) by ietfa.amsl.com (Postfix) with ESMTP id CA69021F977E for ; Fri, 17 May 2013 09:52:06 -0700 (PDT) X-AuditID: 12074422-b7f5b6d00000095d-0a-519660360162 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 5F.E5.02397.63066915; Fri, 17 May 2013 12:52:06 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id r4HGq4TG014213; Fri, 17 May 2013 12:52:05 -0400 Received: from [18.101.8.191] (VPN-18-101-8-191.MIT.EDU [18.101.8.191]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id r4HGq1fb030077 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 17 May 2013 12:52:03 -0400 Message-ID: <51966031.40405@mit.edu> Date: Fri, 17 May 2013 12:52:01 -0400 From: Greg Hudson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130404 Thunderbird/17.0.5 MIME-Version: 1.0 To: Kelley Burgin References: <44302EA3-1CB6-4F9A-A6B4-25F5FCDBCC0A@tycho.ncsc.mil> <51950B13.3090508@mit.edu> <51963800.3010204@mit.edu> <8CB8B53A-1423-45C8-9C1E-7B618B915805@tycho.ncsc.mil> <51963EB8.80202@mit.edu> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJKsWRmVeSWpSXmKPExsUixG6nomuWMC3QYPc0FouvbQ/YLI5uXsVi Ma8hw+L0refMDiweS5b8ZPJ423CV3WPl1NPsHlub/zEGsERx2aSk5mSWpRbp2yVwZSz70MRa sIy54uPSZrYGxnNMXYycHBICJhIN1/+xQNhiEhfurWfrYuTiEBLYxyhx5NYJdghnI6PEu+Nv oTJHmCSu7zzLDNLCK6Ai8ezwdjYQm0VAVWLRzW5WEJtNQFni4NlvYGNFBUIkTn9ugqoXlDg5 8wlYXERAS+LqwzlgcWaBZIm+qevAbGEBD4mHK59BLfvFJHFr0ldGkASngJPEo1nfoW6VlFg0 rZMFollH4l3fA6hB8hLb385hnsAoNAvJvllIymYhKVvAyLyKUTYlt0o3NzEzpzg1Wbc4OTEv L7VI11QvN7NELzWldBMjOAZclHYw/jyodIhRgINRiYd3hvO0QCHWxLLiytxDjJIcTEqivDOj gEJ8SfkplRmJxRnxRaU5qcWHGCU4mJVEeI9/nBooxJuSWFmVWpQPk5LmYFES572WctNfSCA9 sSQ1OzW1ILUIJivDwaEkwdsTDzRUsCg1PbUiLTOnBCHNxMEJMpwHaHgISA1vcUFibnFmOkT+ FKOilDjvCpCEAEgiozQPrheWol4xigO9Isw7C6SKB5je4LpfAQ1mAhrMeg3k6uKSRISUVAOj cXzQLbUHm9xUJ3audbq1N+qCr/OaNVZWQQyaO0/dZrt6zWyGy/lTDWbOp7cFb87v2LPKWz1z n6Dgi8Q5GoxdArPbHvOY8tY8jDIz2DwhkPVxxO57oTYvzwQopGjZTZvKsLKGQWDSZDWPjd+K Hp/3LL4X+Mitb+5U/tuLjrW9Sui8ma/iFL9UiaU4I9FQi7moOBEAlVgY5iwDAAA= Cc: kitten@ietf.org, Sam Hartman Subject: Re: [kitten] Comments on draft-ietf-kitten-aes-cts-hmac-sha2-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 16:52:18 -0000 On 05/17/2013 12:39 PM, Kelley Burgin wrote: > To be clear, in response to Sam's earlier question, are you against a > section discussing random salts which discusses cross realm issues? I am not raising an objection to such a section if it is clearly separate from the enctype specification. (But I also don't see the need for it, and if there is a need, I wonder if it would fit better in the suiteb draft.) From kwburgi@tycho.ncsc.mil Fri May 17 10:24:27 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93CBE11E80F8 for ; Fri, 17 May 2013 10:24:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XKZsF-0No-ns for ; Fri, 17 May 2013 10:24:21 -0700 (PDT) Received: from nsa.gov (emvm-gh1-uea08.nsa.gov [63.239.67.9]) by ietfa.amsl.com (Postfix) with ESMTP id 2DEE121F97B3 for ; Fri, 17 May 2013 10:24:19 -0700 (PDT) X-TM-IMSS-Message-ID: <36bcac490006d1e4@nsa.gov> Received: from tarius.tycho.ncsc.mil ([144.51.31.2]) by nsa.gov ([63.239.67.9]) with ESMTP (TREND IMSS SMTP Service 7.1) id 36bcac490006d1e4 ; Fri, 17 May 2013 13:22:48 -0400 Received: from rd6um-58422h.infosec.tycho.ncsc.mil (rd6um-58422h [192.168.26.151]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id r4HHOFoj017945; Fri, 17 May 2013 13:24:15 -0400 Message-Id: <64EFAFAA-134D-4DB3-B2CE-570FEFFD9360@tycho.ncsc.mil> From: Kelley Burgin To: Greg Hudson In-Reply-To: <51966031.40405@mit.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 17 May 2013 13:27:54 -0400 References: <44302EA3-1CB6-4F9A-A6B4-25F5FCDBCC0A@tycho.ncsc.mil> <51950B13.3090508@mit.edu> <51963800.3010204@mit.edu> <8CB8B53A-1423-45C8-9C1E-7B618B915805@tycho.ncsc.mil> <51963EB8.80202@mit.edu> <51966031.40405@mit.edu> X-Mailer: Apple Mail (2.936) X-Mailman-Approved-At: Fri, 17 May 2013 10:40:42 -0700 Cc: kitten@ietf.org, Sam Hartman Subject: Re: [kitten] Comments on draft-ietf-kitten-aes-cts-hmac-sha2-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 17:24:27 -0000 I agree it might fit better in a different document, but Suite B does not use password based authentication (we require pkinit). The text we have on passwords is to be a complete enctype, that provides a high level of security independent of network security policy (e.g. password strength requirements). I'm happy to include a section in this draft on random salts, if there is a need as you say, and if we can come up with a solution to cross realm problems (I don't have one). On May 17, 2013, at 12:52 PM, Greg Hudson wrote: > On 05/17/2013 12:39 PM, Kelley Burgin wrote: >> To be clear, in response to Sam's earlier question, are you against a >> section discussing random salts which discusses cross realm issues? > > I am not raising an objection to such a section if it is clearly > separate from the enctype specification. (But I also don't see the > need > for it, and if there is a need, I wonder if it would fit better in the > suiteb draft.) > From nico@cryptonector.com Mon May 20 13:11:33 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDFC221F9673 for ; Mon, 20 May 2013 13:11:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7mhcFkOd-RrH for ; Mon, 20 May 2013 13:11:29 -0700 (PDT) Received: from homiemail-a63.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id 1C96521F9670 for ; Mon, 20 May 2013 13:11:29 -0700 (PDT) Received: from homiemail-a63.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTP id 538122F4085 for ; Mon, 20 May 2013 13:11:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=Ttv3yWc0OyvDre+NNZF/ h0rkLn4=; b=fGQ0ak37VeFmaHJYZp5IE6NTDoNw5kKpCHHEwOd9kI6W/hPKEhCo J5pBtP5Ji/JyaaxvjbgdlNOMmOBgy7uC8VAUrgy9ASCtc16PGqOpp9Vuk20Ho67y sTVE9L97m2tX9NfvOL+EmTGaFnQ7K3YzDLljDbWdPw9nIY7EHcfvVn8= Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTPSA id 2D3132F4092 for ; Mon, 20 May 2013 13:10:55 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id hr14so2437188wib.3 for ; Mon, 20 May 2013 13:10:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TOUR4Dj2yQUqPjUfeB42mw0n7lYxUa1RlLJoKJJsDJQ=; b=LJPDI6lbBgzTJMmvah2RGnlp7bxlgSBOJIQ0BTmGkHRimRQsA/AZJvTH5cYUtfkMzD PHdhmokbn7C6sHqpqEHuabaeox5mq540iUtHHO+FTosCUBisUQWwD8ERbMHsyh/Q49v6 6AIVQdmXH/Fn+FKQleyQIm2TpsPzbeaVKxlk5BUtfQ/in0ediyECSQnc/fQ1aIAICZzw Wo/LIL5CbhXFCNnPq3hCQyROwOitAdx4VWCRguh6MaYcUKurAsl7mF4MPehXbeEqKkcG gYEtmMebpLXuVQDySJt5086KvOK0JBqLOMghRn/wsNlyAe/Flq+5qMSV3U5Kr2DhWR01 wv/A== MIME-Version: 1.0 X-Received: by 10.180.39.137 with SMTP id p9mr17103036wik.27.1369080653005; Mon, 20 May 2013 13:10:53 -0700 (PDT) Received: by 10.216.111.132 with HTTP; Mon, 20 May 2013 13:10:52 -0700 (PDT) In-Reply-To: <5192C20A.6040907@mit.edu> References: <5192C20A.6040907@mit.edu> Date: Mon, 20 May 2013 15:10:52 -0500 Message-ID: From: Nico Williams To: Greg Hudson Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org, Sam Hartman Subject: Re: [kitten] Comments on draft-ietf-kitten-aes-cts-hmac-sha2-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2013 20:11:34 -0000 On Tue, May 14, 2013 at 6:00 PM, Greg Hudson wrote: > I have an additional comment: > > Section 6 notes that "[SP800-38A+] requires the plaintext length to be > greater than or equal to the block size" but gives no guidance on what > to do if the input is smaller than that. This seems like a pretty > serious problem. > > The RFC 3962 enctypes do not have this problem because they use a > confounder, which adds a block of input. They did have to specify what > to do when the input length is 0, such that the cipher plaintext is > exactly one block. I agree, this needs to be resolved. It also makes me wonder why no confounder. I don't think we must have confounders (or CTS), and I'd not insist on having them, but I'm curious as to why not keep using confounders. So far my best guess is that confounding increases the *plaintext* size (not just the ciphertext), and this might cause performance problems in some hardware-assisted implementations. I'm not sure what, if anything, we lose by having an IV instead of a confounder. Eavesdroppers get to see the IV, but not the confounder's plaintext, and this presumably leaks some information about the sender's entropy, but it's not clear that we should care, since we assume [and very much depend on having] a decent enough [P]RNG with decent enough seeding [in the PRNG case]. Active attackers also get to modify the IV, but they get to modify the confounder, and any other bit of ciphertext and so on, so this is not an issue. As for what to do when the input is shorter than a full ciphertext block, there are some options. The two most obvious ones are: pad, or confound. My preference would be to confound in this case. Kerberos itself never really needs to encrypt plaintexts shorter than 128 bits today, IIRC, but the GSS mechanism has to support shorter plaintexts, and Kerberos may have to some day for all we know. Nico -- From jhutz@cmu.edu Mon May 20 13:31:43 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B7D321F9665 for ; Mon, 20 May 2013 13:31:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aEODGsUGHQ79 for ; Mon, 20 May 2013 13:31:35 -0700 (PDT) Received: from smtp02.srv.cs.cmu.edu (SMTP02.SRV.CS.CMU.EDU [128.2.217.197]) by ietfa.amsl.com (Postfix) with ESMTP id 57C3E21F962D for ; Mon, 20 May 2013 13:31:35 -0700 (PDT) Received: from [128.2.193.239] (minbar.fac.cs.cmu.edu [128.2.193.239]) (authenticated bits=0) by smtp02.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id r4KKVW6j012048 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 20 May 2013 16:31:32 -0400 (EDT) Message-ID: <1369081891.2711.754.camel@minbar.fac.cs.cmu.edu> From: Jeffrey Hutzelman To: Nico Williams Date: Mon, 20 May 2013 16:31:31 -0400 In-Reply-To: <30001_1369080697_r4KKBaud001485_CAK3OfOh1vEfu1r5TJ8d1pEETBKZW8dD9qBU3_srb-htyuPZ7gg@mail.gmail.com> References: <5192C20A.6040907@mit.edu> <30001_1369080697_r4KKBaud001485_CAK3OfOh1vEfu1r5TJ8d1pEETBKZW8dD9qBU3_srb-htyuPZ7gg@mail.gmail.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 X-Scanned-By: mimedefang-cmuscs on 128.2.217.197 Cc: kitten@ietf.org, Sam Hartman , jhutz@cmu.edu Subject: Re: [kitten] Comments on draft-ietf-kitten-aes-cts-hmac-sha2-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2013 20:31:43 -0000 On Mon, 2013-05-20 at 15:10 -0500, Nico Williams wrote: > As for what to do when the input is shorter than a full ciphertext > block, there are some options. The two most obvious ones are: pad, or > confound. My preference would be to confound in this case. Kerberos > itself never really needs to encrypt plaintexts shorter than 128 bits > today, IIRC, but the GSS mechanism has to support shorter plaintexts, > and Kerberos may have to some day for all we know. RFC3961 also gets used by other protocols, both within and outside the IETF. Some of these do or may include plaintexts shorter than 16 bytes, so IMHO, failing to deal with such short plaintexts is definitely a problem. -- Jeff From nico@cryptonector.com Mon May 20 13:41:12 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 357E321F966B for ; Mon, 20 May 2013 13:41:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qy-Sl6mKDnwT for ; Mon, 20 May 2013 13:41:07 -0700 (PDT) Received: from homiemail-a35.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id 2E3BE21F965B for ; Mon, 20 May 2013 13:41:06 -0700 (PDT) Received: from homiemail-a35.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTP id E96355405B for ; Mon, 20 May 2013 13:41:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=KJd0j4ZJuYMwQPGBAiyZ sMpq5OI=; b=LwNEQa2UVkknUgiCdKLd3Qi1HAPP//kB9GycE1minfK0YP+UA4x3 t9fSgfBxtGJtGuBU02hr2V/J3Kk8SC8XBPBply2vrEaaA4IxgvxJskSKRRC1V72l PDzwxC1TOpkEMmLhDhZk9umMnsjiH3jFzaLn/uLDC3wrohWmdNMFE+A= Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.43]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTPSA id 9346154057 for ; Mon, 20 May 2013 13:41:05 -0700 (PDT) Received: by mail-wg0-f43.google.com with SMTP id c11so5584190wgh.10 for ; Mon, 20 May 2013 13:41:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=n+v5Iw9qi1KOeeOSciSQJ2kiE5tFAEZ8TUCzBl2CNXs=; b=HvlC7YLz2y43M/gei1sE+biipCppSOTE+bpGRsJjKC9FdxeuL0NjNaw+RYtMceL++h 6vz+Ii4nrblkGhBPtSCFcv4jjzpUySSkpQ0RuZtbp3+g6flIOvZYWSxIHArE38FYV0AY FL1+W8JdfDB3Q7yWi7eitkKPKWSqmdN7uBiUin+QxA8QTNKvjNcZyZQ91ebjvQGr77Of 7cUWp4jUuddwTrAloJo99ltgdAMfFr3k6W8W/24vye5kgHhi9umxg0MM9lIwrqe8Sk7R oA+vUcKMFHxlyH0/5gcDWTGivH5B+yM5BPeIe1uyHoMKsWxdqBPvLZ7h1oZfxkyJLRqe /Xjg== MIME-Version: 1.0 X-Received: by 10.180.205.200 with SMTP id li8mr17660794wic.15.1369082464371; Mon, 20 May 2013 13:41:04 -0700 (PDT) Received: by 10.216.111.132 with HTTP; Mon, 20 May 2013 13:41:04 -0700 (PDT) In-Reply-To: References: <44302EA3-1CB6-4F9A-A6B4-25F5FCDBCC0A@tycho.ncsc.mil> Date: Mon, 20 May 2013 15:41:04 -0500 Message-ID: From: Nico Williams To: Sam Hartman Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org Subject: Re: [kitten] Comments on draft-ietf-kitten-aes-cts-hmac-sha2-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2013 20:41:12 -0000 On Thu, May 16, 2013 at 10:26 AM, Sam Hartman wrote: >>>>>> "Kelley" == Kelley Burgin writes: > Kelley> [kwb] Are you ok with "SHOULD include 128-bits of random"? > > Not really. That feels like ignoring an important issue. The point you > bring up about salt seems significant and I think deserves more than a > sentence, especially a SHOULD without qualifications. > > I'd like to first understand from Greg or Ken or whoever looked at > random salts at MIT what the complexities are. > Then I'd like to better understand how you want this requirement > enforced and what attacks you are worried about. In theory randomized salts should have little impact. In practice there are least some moderate impacts (e.g., ktutil-type applications should not assume a salt when generating a keytab entry from a password). I understand the value of randomizing salts, but having *any* salt gets us the most important feature: defeating rainbow table precomputation (by requiring per-principal rainbow tables). Nico -- From tlyu@mit.edu Mon May 20 15:37:12 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9019921F962B for ; Mon, 20 May 2013 15:37:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DCIdLnOZLubF for ; Mon, 20 May 2013 15:37:06 -0700 (PDT) Received: from dmz-mailsec-scanner-8.mit.edu (DMZ-MAILSEC-SCANNER-8.MIT.EDU [18.7.68.37]) by ietfa.amsl.com (Postfix) with ESMTP id DB8BA21F962C for ; Mon, 20 May 2013 15:37:05 -0700 (PDT) X-AuditID: 12074425-b7f986d00000082c-35-519aa590d5e3 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id F6.77.02092.095AA915; Mon, 20 May 2013 18:37:04 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id r4KMb3vf000395; Mon, 20 May 2013 18:37:04 -0400 Received: from cathode-dark-space.mit.edu (CATHODE-DARK-SPACE.MIT.EDU [18.18.1.96]) (authenticated bits=56) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id r4KMb1rT009404 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 20 May 2013 18:37:02 -0400 Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id r4KMb1uW012913; Mon, 20 May 2013 18:37:01 -0400 (EDT) To: Kelley Burgin References: <44302EA3-1CB6-4F9A-A6B4-25F5FCDBCC0A@tycho.ncsc.mil> From: Tom Yu Date: Mon, 20 May 2013 18:37:01 -0400 In-Reply-To: <44302EA3-1CB6-4F9A-A6B4-25F5FCDBCC0A@tycho.ncsc.mil> (Kelley Burgin's message of "Thu, 16 May 2013 11:15:53 -0400") Message-ID: Lines: 19 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmleLIzCtJLcpLzFFi42IR4hTV1p2wdFagwYlTWhZf2x6wWRzdvIrF Yl5DhgOzx5IlP5k8Vk49ze6xtfkfYwBzFJdNSmpOZllqkb5dAlfGtWN72Qv2sFfMPHSOtYHx H2sXIyeHhICJxNe292wQtpjEhXvrgWwuDiGBfYwSZ1tnsEI4GxklTp0+zwLhnGOS+HnyMzuE 08Uosbm3kQWkX0RAS+LqwznMIDazgIXEqRcnmUBsYQEPiYcrn4HtEBIolPj64DJQnIODTUBa 4ujiMpAwi4CqxMlVr8Fmcgo0MkrM+dbLCJLgBZqzb/kisPk8ApwSPRt+sULEBSVOznzCArFL S+LGv5dMExgFZyFJzUKSWsDItIpRNiW3Sjc3MTOnODVZtzg5MS8vtUjXQi83s0QvNaV0EyMo fNldVHcwTjikdIhRgINRiYdXwHBWoBBrYllxZe4hRkkOJiVR3iWLgEJ8SfkplRmJxRnxRaU5 qcWHGCU4mJVEeL83A+V4UxIrq1KL8mFS0hwsSuK8N1Ju+gsJpCeWpGanphakFsFkZTg4lCR4 GYBxKiRYlJqeWpGWmVOCkGbi4AQZzgM03Bqkhre4IDG3ODMdIn+KUZdj8/nJ7xiFWPLy81Kl xHl1QIoEQIoySvPg5sDSzitGcaC3hHlFQKp4gCkLbtIroCVMQEu2W84EWVKSiJCSamCckr93 ygy/prCq2GXnRNz5FLc/FdOXOmRe+3OaWLRI4eSA/r7dTuxbTMyYHLb19qqKn87bt/3Ak7QU ftE5uZdF1OJOL9y/8pn7YsHPx+d3REo5zgmebtoa4Lr0xYtdPyw0w5gruLki7Ctfu39znfi/ v/LQPwV9Nyc37qNvZy8WfVe+y965brMSS3FGoqEWc1FxIgB+fdGxFgMAAA== Cc: kitten@ietf.org, Sam Hartman Subject: Re: [kitten] Comments on draft-ietf-kitten-aes-cts-hmac-sha2-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2013 22:37:12 -0000 Kelley Burgin writes: > [kwb] CTS won't work, so two work arounds are: > 1. Pad the plaintext to a block length, but this brings back issues > with the ciphertext length being greater than plaintext length. > 2. Use a different mode, counter mode for example (only in this > special case). Encrypt the IV and xor the result with the plaintext > (padded with zeros). Output the appropriate partial ciphertext so > there's no expansion. I think CTS will work if you are willing to modify the "IV" sent when the plaintext length is less than or equal to the block size; basically treat the IV as the next to last block of CBC ciphertext, truncating it to the length of the plaintext, and send the final block of CBC ciphertext as the "IV". I'm not sure how to adapt this approach to the current document, because the current approach doesn't send the IV, but rather sends the nonce from which the IV is derived. From nico@cryptonector.com Mon May 20 16:13:45 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE80D21F9699 for ; Mon, 20 May 2013 16:13:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_12=0.6, J_CHICKENPOX_42=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dmuu7JjPnGxq for ; Mon, 20 May 2013 16:13:40 -0700 (PDT) Received: from homiemail-a73.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id D5B6E21F9697 for ; Mon, 20 May 2013 16:13:40 -0700 (PDT) Received: from homiemail-a73.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a73.g.dreamhost.com (Postfix) with ESMTP id 856E61F008A for ; Mon, 20 May 2013 16:13:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=LPwrgrppMaHPYXW6AMcK 2uzC1Yc=; b=DutgQiBm2nQXmmDJ1zRGXw04XpAjHuOkZzoqi5F0ieNUx7ruF4v9 5AvSXPi/U71iQnjhVp7TKhATuaAUE5AH1mAlYwVbCN8Pm1lZzVQZeKDGtH9CqU/1 iyRgPuFS9fAIbYUzLim0SHQgYwRqzZKFBOBaI+Dl5nPM1cRCwrKLvrM= Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a73.g.dreamhost.com (Postfix) with ESMTPSA id 25DF21F0087 for ; Mon, 20 May 2013 16:13:39 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id hr14so2546692wib.10 for ; Mon, 20 May 2013 16:13:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TOOaIacXrKXFkWjI4QPDk7uN8UWCAL4wN9opfrFTLjU=; b=kR+4wIRUsaH/jzoPk/lY6e9FR/RmxvKKr1Cit8+tYkCiwMR/LeTcHad9hmI6wEqUhR AqTWKR0w5S1JkhaNIXXsw7cDFUGY9Ld6c10EAqYh08Op1pcXDWLnxteV1rzM2nuYxa+d 5+jDRm20xy7B8NDZvyiJk3n1yzSDghmcxkwaPpSLDWQYPw3U+gRFzwaRWW1ys+v2hU0r CGzbnMWK7lVgTU79Ap8n5ZkblEY6o/bzielig3EB0u9jFEnMN5pIcuXyIv5x/lIy4e35 LGeAuB9B+XyH2klAsFyR0ps3laX0Y1+JIuNr7A3+x00woJeRfNpf7nI7N20s0qsNvgvL LqxQ== MIME-Version: 1.0 X-Received: by 10.180.210.225 with SMTP id mx1mr18621008wic.15.1369091618760; Mon, 20 May 2013 16:13:38 -0700 (PDT) Received: by 10.216.111.132 with HTTP; Mon, 20 May 2013 16:13:38 -0700 (PDT) In-Reply-To: References: <44302EA3-1CB6-4F9A-A6B4-25F5FCDBCC0A@tycho.ncsc.mil> Date: Mon, 20 May 2013 18:13:38 -0500 Message-ID: From: Nico Williams To: Tom Yu Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org, Sam Hartman Subject: Re: [kitten] Comments on draft-ietf-kitten-aes-cts-hmac-sha2-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2013 23:13:46 -0000 On Mon, May 20, 2013 at 5:37 PM, Tom Yu wrote: > Kelley Burgin writes: > >> [kwb] CTS won't work, so two work arounds are: >> 1. Pad the plaintext to a block length, but this brings back issues >> with the ciphertext length being greater than plaintext length. >> 2. Use a different mode, counter mode for example (only in this >> special case). Encrypt the IV and xor the result with the plaintext >> (padded with zeros). Output the appropriate partial ciphertext so >> there's no expansion. > > I think CTS will work if you are willing to modify the "IV" sent when > the plaintext length is less than or equal to the block size; > basically treat the IV as the next to last block of CBC ciphertext, > truncating it to the length of the plaintext, and send the final block > of CBC ciphertext as the "IV". > > I'm not sure how to adapt this approach to the current document, > because the current approach doesn't send the IV, but rather sends the > nonce from which the IV is derived. I don't see the problem. In the short-plaintext case we'd have: C = E(Ke, N | plaintext, cipherstate) H = HMAC(Ki, C) ciphertext = C and corresponding change to the decrypt side: (C, H) = ciphertext if (H != HMAC(Ki, C)[1..h]) stop, report error IV = cipherstate (N, P) = D(Ke, C, IV) cipherState = N I remembered a reason not to confound whenever possible: performance -- fewer encryption/decryption operations. Nico -- From hotz@jpl.nasa.gov Mon May 20 16:46:26 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CC4A21F9630 for ; Mon, 20 May 2013 16:46:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zTDjEgR+6EgM for ; Mon, 20 May 2013 16:46:15 -0700 (PDT) Received: from mail.jpl.nasa.gov (smtp.jpl.nasa.gov [128.149.139.105]) by ietfa.amsl.com (Postfix) with ESMTP id B426421F95EA for ; Mon, 20 May 2013 16:46:15 -0700 (PDT) Received: from dhcp-128-149-179-217.jpl.nasa.gov (dhcp-128-149-179-217.jpl.nasa.gov [128.149.179.217]) (authenticated (0 bits)) by smtp.jpl.nasa.gov (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r4KNkAAX020517 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO); Mon, 20 May 2013 16:46:11 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: "Henry B. Hotz" In-Reply-To: <51950B13.3090508@mit.edu> Date: Mon, 20 May 2013 16:46:13 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <9CF67687-6B74-490A-B350-63D0541DD4E4@jpl.nasa.gov> References: <44302EA3-1CB6-4F9A-A6B4-25F5FCDBCC0A@tycho.ncsc.mil> <51950B13.3090508@mit.edu> To: Greg Hudson X-Mailer: Apple Mail (2.1503) X-Source-Sender: hotz@jpl.nasa.gov X-AUTH: Authorized Cc: kitten@ietf.org, Sam Hartman Subject: Re: [kitten] Comments on draft-ietf-kitten-aes-cts-hmac-sha2-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2013 23:46:26 -0000 Obviously off-topic, but I've advocated for a "keytab import" = administrative function as a way to avoid retyping passwords in this = case. Yeah, yeah, "write it yourself, it's open-source", I know. On May 16, 2013, at 9:36 AM, Greg Hudson wrote: > * Cross-realm TGTs are currently managed by entering the same password > at two KDCs to get the same keys. If each KDC uses a random salt, = they > won't have the same keys. ------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu From nico@cryptonector.com Mon May 20 17:04:22 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A7BE21F96E8 for ; Mon, 20 May 2013 17:04:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U+5xpxgh4yh5 for ; Mon, 20 May 2013 17:04:17 -0700 (PDT) Received: from homiemail-a30.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id 8042521F96E4 for ; Mon, 20 May 2013 17:04:17 -0700 (PDT) Received: from homiemail-a30.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTP id 2D90521DE65 for ; Mon, 20 May 2013 17:04:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:date:message-id:subject:from:to:cc:content-type; s= cryptonector.com; bh=JCwbKiGzzDKX5g213MPK8OjFxJw=; b=o1wzAPbVOpC RohCAesnSUPjGzbH3edqXhzdk1dZzOlblO/bntAo7F0xNrQYGBKLiyf7fGLWNyAr X1Flb6CnL60IYTQMlKR2F8agscMijfdFgl1AXkH1jU08+tpt/OA7TfIkbTQyLp5k 06bQVYb2KnvnhIemxLXPYs6DIaXi6r6U= Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTPSA id C386121DE58 for ; Mon, 20 May 2013 17:04:16 -0700 (PDT) Received: by mail-wg0-f52.google.com with SMTP id z11so13704wgg.19 for ; Mon, 20 May 2013 17:04:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=rNjOaLj1CIudTJKoOp7zlVh9F+bMDy2Kj51mvzaoDTI=; b=GYLuO/C0KFQaWmU6QifOYLNR23qBfV9+GjS/OhYkyVlCIovEplpW+0iivm1awiT8Wd M3uaHY+q44IYRv6Cc0oE9yz+k6Gm51hpKFa8Eaecm+Xk2jqzRd5U8BjyqU28SYHJnia5 lSafKuuTc+f9/RYwIHjQv7I8kpznse/iiNFb3OATvO8ue8s/mhzu3aLpuUqVoJVmsdF3 FlWODAcBs9k4tTa2jn01Myuy34k1+1eC4AKHllt/UKkxebg8cezaEF0e7Qfv9ff8xSap VwucVAgkU4u2Hf8scjPa2KjoeCMD7RiPqZT0aSccH/l1G2MP9/72xvzsBU/rtVD9ymSV f/qA== MIME-Version: 1.0 X-Received: by 10.180.210.225 with SMTP id mx1mr18848547wic.15.1369094655330; Mon, 20 May 2013 17:04:15 -0700 (PDT) Received: by 10.216.111.132 with HTTP; Mon, 20 May 2013 17:04:15 -0700 (PDT) Date: Mon, 20 May 2013 19:04:15 -0500 Message-ID: From: Nico Williams To: "Henry B. Hotz" Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org, Sam Hartman Subject: [kitten] OT: ktutil and x-realm keys (Re: Comments on draft-ietf-kitten-aes-cts-hmac-sha2-00) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 00:04:22 -0000 On Mon, May 20, 2013 at 6:46 PM, Henry B. Hotz wrote: > On May 16, 2013, at 9:36 AM, Greg Hudson wrote: >> * Cross-realm TGTs are currently managed by entering the same password >> at two KDCs to get the same keys. If each KDC uses a random salt, they >> won't have the same keys. > > Obviously off-topic, but I've advocated for a "keytab import" administrative function as a way to avoid retyping passwords in this case. Yeah, yeah, "write it yourself, it's open-source", I know. I don't think that's the best way to implement this. As long as we must have password-based x-realm keys the way it should work is that one admin creates an x-realm princ on on realm, then the other realm's admin does an AS exchange to fetch the salt (and other s2kparams) and validate the password they've been told on the phone/whatever, then the key gets added to that realm. This is, also, how password-based keys should be added to keytabs (to fetch the salt and other s2kparams). But this is off-topic, and also off-topic: we really need password-authenticated DH-exchanged x-realm keys and PKI-authenticated DH-exchanged x-realm keys. I.e., PKCROSS. Nico -- From tlyu@mit.edu Mon May 20 17:23:24 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE31321F96BB for ; Mon, 20 May 2013 17:23:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.999 X-Spam-Level: X-Spam-Status: No, score=-102.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3HG8P7asFAIJ for ; Mon, 20 May 2013 17:23:18 -0700 (PDT) Received: from dmz-mailsec-scanner-1.mit.edu (DMZ-MAILSEC-SCANNER-1.MIT.EDU [18.9.25.12]) by ietfa.amsl.com (Postfix) with ESMTP id 3973C21F9301 for ; Mon, 20 May 2013 17:23:18 -0700 (PDT) X-AuditID: 1209190c-b7f566d000004c69-3d-519abe75d371 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id A0.55.19561.57EBA915; Mon, 20 May 2013 20:23:17 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id r4L0LuLp009789; Mon, 20 May 2013 20:21:57 -0400 Received: from cathode-dark-space.mit.edu (CATHODE-DARK-SPACE.MIT.EDU [18.18.1.96]) (authenticated bits=56) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id r4L0LfX8015537 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 20 May 2013 20:21:55 -0400 Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id r4L0Lf8M013264; Mon, 20 May 2013 20:21:41 -0400 (EDT) To: Nico Williams References: <44302EA3-1CB6-4F9A-A6B4-25F5FCDBCC0A@tycho.ncsc.mil> From: Tom Yu Date: Mon, 20 May 2013 20:21:40 -0400 In-Reply-To: (Nico Williams's message of "Mon, 20 May 2013 18:13:38 -0500") Message-ID: Lines: 42 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplleLIzCtJLcpLzFFi42IR4hTV1i3dNyvQ4HyTksXXtgdsFkc3r2Kx OHXtCJsDs8fLU+cYPZYs+cnksXLqafYA5igum5TUnMyy1CJ9uwSujKd/97MW3OStmNm4mKmB 8QlXFyMnh4SAiUTX95ksELaYxIV769m6GLk4hAT2MUoc+d7HCuFsZJSYd+kWO4RzjkmiYW07 I4TTxSixYsoBZpB+EQFNievzlrKB2MwCmRLHFvxkBLGFBTwkHq58BjX3OaPEgltrgRZycLAJ SEscXVwGUsMioCpx420T2AZOgQmMEt9vfmUHSfAKWEh8PLMbzOYR4JSYfuMWK0RcUOLkzCcs EMu0JG78e8k0gVFwFpLULCSpBYxMqxhlU3KrdHMTM3OKU5N1i5MT8/JSi3QN9XIzS/RSU0o3 MYJDWJJnB+Obg0qHGAU4GJV4eAUNZwUKsSaWFVfmHmKU5GBSEuXN3wkU4kvKT6nMSCzOiC8q zUktPsQowcGsJML7vRkox5uSWFmVWpQPk5LmYFES572cctNfSCA9sSQ1OzW1ILUIJivDwaEk wVu+F6hRsCg1PbUiLTOnBCHNxMEJMpwHaHg+SA1vcUFibnFmOkT+FKMux+bzk98xCrHk5eel SonzZoEUCYAUZZTmwc2BpZ5XjOJAbwnzNoBU8QDTFtykV0BLmICWbLecCbKkJBEhJdXAGLLm 09U/6tMD7i0SuDrbqv7/g1aH93qNHD2trG9ftuwv5/icYbqi+/u/Is6z2tWsHQaLm+7+l2rN yXbPnFB07LtBvlvN7W9nVI2P/Vt5S8s4VO5d/Ym3Wlt83NJye/Qqyyaecjp8+nH83xM7/96f 4LD7xvq733SV3h55c7P306dKqytyNfp5e5RYijMSDbWYi4oTATaE0T8YAwAA Cc: kitten@ietf.org, Sam Hartman Subject: Re: [kitten] Comments on draft-ietf-kitten-aes-cts-hmac-sha2-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 00:23:24 -0000 Nico Williams writes: > On Mon, May 20, 2013 at 5:37 PM, Tom Yu wrote: >> Kelley Burgin writes: >> >>> [kwb] CTS won't work, so two work arounds are: >>> 1. Pad the plaintext to a block length, but this brings back issues >>> with the ciphertext length being greater than plaintext length. >>> 2. Use a different mode, counter mode for example (only in this >>> special case). Encrypt the IV and xor the result with the plaintext >>> (padded with zeros). Output the appropriate partial ciphertext so >>> there's no expansion. >> >> I think CTS will work if you are willing to modify the "IV" sent when >> the plaintext length is less than or equal to the block size; >> basically treat the IV as the next to last block of CBC ciphertext, >> truncating it to the length of the plaintext, and send the final block >> of CBC ciphertext as the "IV". >> >> I'm not sure how to adapt this approach to the current document, >> because the current approach doesn't send the IV, but rather sends the >> nonce from which the IV is derived. > > I don't see the problem. In the short-plaintext case we'd have: > > C = E(Ke, N | plaintext, cipherstate) > H = HMAC(Ki, C) > ciphertext = C That's not quite right, unless you're redefining E. If E is SP800-38A+ "CBC-CS3", it doesn't really work unless len(plaintext) is greater than the blocksize. We can still send a truncated nonce instead of a truncated IV, because we can recover the entire IV on decryption. plen = len(plaintext) if plen < blocksize: C = Enc-CBC(Ke, plaintext | nullpad, IV) N1 = C[1..blocksize] C1 = N[1..plen] H = HMAC(Ki, N1 | C1) ciphertext = N1 | C1 | H[1..h] From nico@cryptonector.com Mon May 20 17:56:36 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9BE921F9761 for ; Mon, 20 May 2013 17:56:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.177 X-Spam-Level: X-Spam-Status: No, score=-1.177 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_12=0.6, J_CHICKENPOX_42=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2aVF2tHCNFJN for ; Mon, 20 May 2013 17:56:30 -0700 (PDT) Received: from homiemail-a65.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id DCFA821F95E4 for ; Mon, 20 May 2013 17:56:30 -0700 (PDT) Received: from homiemail-a65.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a65.g.dreamhost.com (Postfix) with ESMTP id 688E37E405D for ; Mon, 20 May 2013 17:56:25 -0700 (PDT) Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a65.g.dreamhost.com (Postfix) with ESMTPSA id 187287E4058 for ; Mon, 20 May 2013 17:56:24 -0700 (PDT) Received: by mail-wi0-f181.google.com with SMTP id hi5so27251wib.8 for ; Mon, 20 May 2013 17:56:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9xW+8MVsRY1uRGCdMGR6drMS3wJUMbEO2nynwoAxn8o=; b=F61BplHXDr0lw2gg8WSluLfKIDKbiDDbUsGAWWNr0iMsuRQFH2cIvxc/gSv5yDluhH joTsmhHv3RAvZD6z31WJxUA6joN8NRCpGMZxsXN7md1t1hTlq6Iy9dDKeyqiEOMZXM3V PATUdTOEKrbCQa1FmLquI8zbA9tzHpMgM7vmcWxHgmP2nTwq9gGxCbK3SUH0TPRO/rEY Bn58698qwsHfOps7sasnJFaoluEfBiKoy5SHnhI4MObppNzcxWBx8yWuld84qrpnsbq/ +ZbFbUjbqHoHa7qNFKG8Zb9aLXs7VZMGjCBpwgPJVZNDDZyGLn1VKFKVshDqh/tiFI3X kViw== MIME-Version: 1.0 X-Received: by 10.180.205.206 with SMTP id li14mr18670822wic.33.1369097783584; Mon, 20 May 2013 17:56:23 -0700 (PDT) Received: by 10.216.111.132 with HTTP; Mon, 20 May 2013 17:56:23 -0700 (PDT) In-Reply-To: References: <44302EA3-1CB6-4F9A-A6B4-25F5FCDBCC0A@tycho.ncsc.mil> Date: Mon, 20 May 2013 19:56:23 -0500 Message-ID: From: Nico Williams To: Tom Yu Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org, Sam Hartman Subject: Re: [kitten] Comments on draft-ietf-kitten-aes-cts-hmac-sha2-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 00:56:36 -0000 On Mon, May 20, 2013 at 7:21 PM, Tom Yu wrote: > Nico Williams writes: > >> On Mon, May 20, 2013 at 5:37 PM, Tom Yu wrote: >>> Kelley Burgin writes: >>> >>>> [kwb] CTS won't work, so two work arounds are: >>>> 1. Pad the plaintext to a block length, but this brings back issues >>>> with the ciphertext length being greater than plaintext length. >>>> 2. Use a different mode, counter mode for example (only in this >>>> special case). Encrypt the IV and xor the result with the plaintext >>>> (padded with zeros). Output the appropriate partial ciphertext so >>>> there's no expansion. >>> >>> I think CTS will work if you are willing to modify the "IV" sent when >>> the plaintext length is less than or equal to the block size; >>> basically treat the IV as the next to last block of CBC ciphertext, >>> truncating it to the length of the plaintext, and send the final block >>> of CBC ciphertext as the "IV". >>> >>> I'm not sure how to adapt this approach to the current document, >>> because the current approach doesn't send the IV, but rather sends the >>> nonce from which the IV is derived. >> >> I don't see the problem. In the short-plaintext case we'd have: >> >> C = E(Ke, N | plaintext, cipherstate) >> H = HMAC(Ki, C) >> ciphertext = C > > That's not quite right, unless you're redefining E. If E is > SP800-38A+ "CBC-CS3", it doesn't really work unless len(plaintext) is > greater than the blocksize. We can still send a truncated nonce > instead of a truncated IV, because we can recover the entire IV on > decryption. Here E() operates on a plaintext 16-31 bytes long: E | P. There's no problem. From tlyu@mit.edu Mon May 20 20:59:00 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7304B21F973E for ; Mon, 20 May 2013 20:59:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.699 X-Spam-Level: X-Spam-Status: No, score=-102.699 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RjAzGWB9rRry for ; Mon, 20 May 2013 20:58:54 -0700 (PDT) Received: from dmz-mailsec-scanner-1.mit.edu (DMZ-MAILSEC-SCANNER-1.MIT.EDU [18.9.25.12]) by ietfa.amsl.com (Postfix) with ESMTP id 5BF9021F9747 for ; Mon, 20 May 2013 20:58:49 -0700 (PDT) X-AuditID: 1209190c-b7f566d000004c69-0f-519af0f8f089 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 03.5E.19561.8F0FA915; Mon, 20 May 2013 23:58:48 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id r4L3wjhh015420; Mon, 20 May 2013 23:58:45 -0400 Received: from cathode-dark-space.mit.edu (CATHODE-DARK-SPACE.MIT.EDU [18.18.1.96]) (authenticated bits=56) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id r4L3wgtD025247 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 20 May 2013 23:58:44 -0400 Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id r4L3wgiU013844; Mon, 20 May 2013 23:58:42 -0400 (EDT) To: Nico Williams References: <44302EA3-1CB6-4F9A-A6B4-25F5FCDBCC0A@tycho.ncsc.mil> From: Tom Yu Date: Mon, 20 May 2013 23:58:41 -0400 In-Reply-To: (Nico Williams's message of "Mon, 20 May 2013 19:56:23 -0500") Message-ID: Lines: 43 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjleLIzCtJLcpLzFFi42IRYrdT0f3xYVagwaFl+hZf2x6wWRzdvIrF Yl5DhsWpa0fYHFg8Xp46x+ixZMlPJo+VU0+ze2xt/scYwBLFZZOSmpNZllqkb5fAlfHs4Tzm gk/8FbcnHWFrYLzL08XIySEhYCLRcX4fK4QtJnHh3nq2LkYuDiGBfYwSV64fZYJwNjJKbD5x hRXCOcckMef5ehYIp4tRYuf0Kcwg/SICmhLX5y1lA7GZBTIlji34yQhiCwt4SDxc+Qxq7l0m iQVdU4ESHBxsAtISRxeXgdSwCKhK/Fg+jx2khlNgAqPE+mvfwYbyClhI3DswEczmEeCUuHF7 LRNEXFDi5MwnLBDLtCRu/HvJNIFRcBaS1CwkqQWMTKsYZVNyq3RzEzNzilOTdYuTE/PyUot0 DfVyM0v0UlNKNzGCgppTkmcH45uDSocYBTgYlXh4BQ1nBQqxJpYVV+YeYpTkYFIS5fV9DxTi S8pPqcxILM6ILyrNSS0+xCjBwawkwvu9GSjHm5JYWZValA+TkuZgURLnvZxy019IID2xJDU7 NbUgtQgmK8PBoSTBewNkqGBRanpqRVpmTglCmomDE2Q4D9BwK5Aa3uKCxNzizHSI/ClGXY7N 5ye/YxRiycvPS5US5/0GUiQAUpRRmgc3B5aMXjGKA70lzHsRpIoHmMjgJr0CWsIEtGS75UyQ JSWJCCmpBsb5dhrnQr7Hz/D7LfZx1cwTu0UO1Ftuv7a791HM8kiP16J34gtm6TFdubvKvTLv 9MFlPpYsnoxGqZ0BHWnC1Q7eCdM1c3tTre2MmxaLfGZ4Xjvn6mtO0ytnnplLJT5JXVMuHj99 Up/ouWM55a1OO9ZOu/g62fmSTM23lSIbNfgunvBJLz4cVanEUpyRaKjFXFScCACeiWTcIQMA AA== Cc: kitten@ietf.org, Sam Hartman Subject: Re: [kitten] Comments on draft-ietf-kitten-aes-cts-hmac-sha2-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 03:59:00 -0000 Nico Williams writes: > On Mon, May 20, 2013 at 7:21 PM, Tom Yu wrote: >> Nico Williams writes: >> >>> On Mon, May 20, 2013 at 5:37 PM, Tom Yu wrote: >>>> Kelley Burgin writes: >>>> >>>>> [kwb] CTS won't work, so two work arounds are: >>>>> 1. Pad the plaintext to a block length, but this brings back issues >>>>> with the ciphertext length being greater than plaintext length. >>>>> 2. Use a different mode, counter mode for example (only in this >>>>> special case). Encrypt the IV and xor the result with the plaintext >>>>> (padded with zeros). Output the appropriate partial ciphertext so >>>>> there's no expansion. >>>> >>>> I think CTS will work if you are willing to modify the "IV" sent when >>>> the plaintext length is less than or equal to the block size; >>>> basically treat the IV as the next to last block of CBC ciphertext, >>>> truncating it to the length of the plaintext, and send the final block >>>> of CBC ciphertext as the "IV". >>>> >>>> I'm not sure how to adapt this approach to the current document, >>>> because the current approach doesn't send the IV, but rather sends the >>>> nonce from which the IV is derived. >>> >>> I don't see the problem. In the short-plaintext case we'd have: >>> >>> C = E(Ke, N | plaintext, cipherstate) >>> H = HMAC(Ki, C) >>> ciphertext = C >> >> That's not quite right, unless you're redefining E. If E is >> SP800-38A+ "CBC-CS3", it doesn't really work unless len(plaintext) is >> greater than the blocksize. We can still send a truncated nonce >> instead of a truncated IV, because we can recover the entire IV on >> decryption. > > Here E() operates on a plaintext 16-31 bytes long: E | P. There's no problem. I think you mean the plaintext is N | plaintext. It sounds like you're making the short-plaintext encryption change to using a confounder, which the current document seems to deliberately avoid. From nico@cryptonector.com Mon May 20 21:45:51 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54EAA21F975B for ; Mon, 20 May 2013 21:45:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.077 X-Spam-Level: X-Spam-Status: No, score=-1.077 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_12=0.6, J_CHICKENPOX_42=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8fWaWD5VGIhV for ; Mon, 20 May 2013 21:45:46 -0700 (PDT) Received: from homiemail-a30.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id 5023421F869F for ; Mon, 20 May 2013 21:45:46 -0700 (PDT) Received: from homiemail-a30.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTP id C2F2121DE77 for ; Mon, 20 May 2013 21:45:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=0wplai2VPOdlRM1xHd4V K6MVuug=; b=S2Q7b67exYaw75MlbfyFkvu1VZQnC3uIDEeqPTkL2Vr8aA5GjKa7 rKLrnWG3ttCzFXppbDzsPCceuWwY4gVh+xNX6hs2cZeWW45iESFwOp35oUyTNicK N7Cba8GVkPpMfneOUWu1TilpumCYJiRAeIUVkS88H4lW5nrx3+a322g= Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTPSA id 70BA021DE6A for ; Mon, 20 May 2013 21:45:45 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id ey16so2634769wid.5 for ; Mon, 20 May 2013 21:45:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+KtUESwG2IvPccALHPbQDoNjJGRg3ON3BbSs9i/zlL4=; b=jNgKCjGYoRmrH/pLLEXFRmEWyK+BoEwMzea+eGQ8eKngddT5gXLk+gjx+O6OJ5vFd8 bI0p96wp9/HQlmPYZd/atxVWGMtrzSjIbiyLniTrzsIREqRahRi8NCCIBJPj0AfkKQJt K77cjMueRnKlbpShfZIcXKKpkgzExsSV0uA+VY1HtRMOl0NkBGNG9n9LSndYnsafiRpE ToyBj+ZC1IL+RWykL87Q/ytBlbT5CZYYN7Ppx6JzrH0cX79ATrCWggH2WLZT4yabN5oy J/YugB7md3fhZ3a6Wj+jTJzAaSc0j8eGUCuplxSfBrKEDTk5bcyf6U6CU47pQzvcUU/E McZA== MIME-Version: 1.0 X-Received: by 10.181.13.229 with SMTP id fb5mr1027146wid.16.1369111544076; Mon, 20 May 2013 21:45:44 -0700 (PDT) Received: by 10.216.111.132 with HTTP; Mon, 20 May 2013 21:45:43 -0700 (PDT) In-Reply-To: References: <44302EA3-1CB6-4F9A-A6B4-25F5FCDBCC0A@tycho.ncsc.mil> Date: Mon, 20 May 2013 23:45:43 -0500 Message-ID: From: Nico Williams To: Tom Yu Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org, Sam Hartman Subject: Re: [kitten] Comments on draft-ietf-kitten-aes-cts-hmac-sha2-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 04:45:51 -0000 On Mon, May 20, 2013 at 10:58 PM, Tom Yu wrote: > Nico Williams writes: >> On Mon, May 20, 2013 at 7:21 PM, Tom Yu wrote: >>> Nico Williams writes: >>>> I don't see the problem. In the short-plaintext case we'd have: >>>> >>>> C = E(Ke, N | plaintext, cipherstate) >>>> H = HMAC(Ki, C) >>>> ciphertext = C >>> >>> That's not quite right, unless you're redefining E. If E is >>> SP800-38A+ "CBC-CS3", it doesn't really work unless len(plaintext) is >>> greater than the blocksize. We can still send a truncated nonce >>> instead of a truncated IV, because we can recover the entire IV on >>> decryption. >> >> Here E() operates on a plaintext 16-31 bytes long: E | P. There's no problem. > > I think you mean the plaintext is N | plaintext. It sounds like That's what I wrote, yes :) > you're making the short-plaintext encryption change to using a > confounder, which the current document seems to deliberately avoid. I don't know why the current document avoids confounding, not even whether it does so deliberately or by accident -- the topic is not addressed. Section 1 addresses differences from aes-cts-hmac-sha-1, but does not cover this one; it should. Nico -- From kwburgi@tycho.ncsc.mil Tue May 21 09:15:18 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A9FB21F93BA for ; Tue, 21 May 2013 09:15:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qtelv2D5EfT1 for ; Tue, 21 May 2013 09:15:11 -0700 (PDT) Received: from nsa.gov (emvm-gh1-uea09.nsa.gov [63.239.67.10]) by ietfa.amsl.com (Postfix) with ESMTP id 19C7921F9874 for ; Tue, 21 May 2013 09:15:10 -0700 (PDT) X-TM-IMSS-Message-ID: <274e587e00090501@nsa.gov> Received: from tarius.tycho.ncsc.mil ([144.51.31.2]) by nsa.gov ([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1) id 274e587e00090501 ; Tue, 21 May 2013 12:18:08 -0400 Received: from rd6um-58422h.infosec.tycho.ncsc.mil (rd6um-58422h [192.168.26.151]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id r4LGF6Qr021560; Tue, 21 May 2013 12:15:07 -0400 Message-Id: <7E40423E-7040-4AD5-9135-97032369CAC0@tycho.ncsc.mil> From: Kelley Burgin To: Nico Williams In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 21 May 2013 12:18:55 -0400 References: <44302EA3-1CB6-4F9A-A6B4-25F5FCDBCC0A@tycho.ncsc.mil> X-Mailer: Apple Mail (2.936) Cc: kitten@ietf.org, Sam Hartman Subject: Re: [kitten] Comments on draft-ietf-kitten-aes-cts-hmac-sha2-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 16:15:18 -0000 Both Tom's and Nico's short-plaintext schemes miss something I'm looking for: the presence of the IV in the MAC computation. Otherwise the MAC value H is always the same for a given C (output of the encryption operation). In general, we want to encrypt-then-mac, include the IV directly in the MAC computation and on the receiving end check the MAC before decryption (to save decrypting a long message only to find out later that the MAC doesn't verify). I'm probably fine with a scheme that doesn't do the last two in short-plaintext cases (like Tom's and Nico's). However, to achieve all three, the nonce needs to be sent as part of the ciphertext. Here are my comments on the two proposed short-plaintext schemes: In Tom's scheme for short-plaintext cases, it seems that duplicate information is being sent, if I understand correctly: isn't C1 a subset of the bits of N1? If so, it would be useful to include part of the IV in the MAC computation instead of C1 to diversify the MAC values for a given C. Tom's: [ plen = len(plaintext) if plen < blocksize: C = Enc-CBC(Ke, plaintext | nullpad, IV) N1 = C[1..blocksize] C1 = N[1..plen] H = HMAC(Ki, N1 | C1) ciphertext = N1 | C1 | H[1..h] ] could change to (note the receiver has to decrypt first to recover the IV, then verify the MAC) [ plen = len(plaintext) if plen < blocksize: C = Enc-CBC(Ke, plaintext | nullpad, IV) IV* = IV[1..plen] <-- don't truncate N1, use IV instead H = HMAC(Ki, C | IV*) ciphertext = C | IV* | H[1..h] ] Nico's could also be modified to include the IV in the MAC computation, without expanding the ciphertext: Nico's: [ C = E(Ke, N | plaintext, cipherstate) H = HMAC(Ki, C) ciphertext = C, H and corresponding change to the decrypt side: (C, H) = ciphertext if (H != HMAC(Ki, C)[1..h]) stop, report error IV = cipherstate (N, P) = D(Ke, C, IV) cipherState = N ] could change to [ C = E(Ke, N | plaintext, cipherstate) H = HMAC(Ki, N | C) <-- added nonce here ciphertext = C, H decrypt (C, H) = ciphertext IV = cipherstate <-- decrypt first to recover the nonce, then check MAC (N, P) = D(Ke, C, IV) if (H != HMAC(Ki, N | C)[1..h]) stop, report error cipherState = N ] On May 21, 2013, at 12:45 AM, Nico Williams wrote: > On Mon, May 20, 2013 at 10:58 PM, Tom Yu wrote: >> Nico Williams writes: >>> On Mon, May 20, 2013 at 7:21 PM, Tom Yu wrote: >>>> Nico Williams writes: >>>>> I don't see the problem. In the short-plaintext case we'd have: >>>>> >>>>> C = E(Ke, N | plaintext, cipherstate) >>>>> H = HMAC(Ki, C) >>>>> ciphertext = C >>>> >>>> That's not quite right, unless you're redefining E. If E is >>>> SP800-38A+ "CBC-CS3", it doesn't really work unless >>>> len(plaintext) is >>>> greater than the blocksize. We can still send a truncated nonce >>>> instead of a truncated IV, because we can recover the entire IV on >>>> decryption. >>> >>> Here E() operates on a plaintext 16-31 bytes long: E | P. There's >>> no problem. >> >> I think you mean the plaintext is N | plaintext. It sounds like > > That's what I wrote, yes :) > >> you're making the short-plaintext encryption change to using a >> confounder, which the current document seems to deliberately avoid. > > I don't know why the current document avoids confounding, not even > whether it does so deliberately or by accident -- the topic is not > addressed. Section 1 addresses differences from aes-cts-hmac-sha-1, > but does not cover this one; it should. > > Nico > -- From jhutz@cmu.edu Tue May 21 09:48:58 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 294DF21F974B for ; Tue, 21 May 2013 09:48:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y9U0Qu724u00 for ; Tue, 21 May 2013 09:48:52 -0700 (PDT) Received: from smtp03.srv.cs.cmu.edu (SMTP03.SRV.CS.CMU.EDU [128.2.217.198]) by ietfa.amsl.com (Postfix) with ESMTP id 3364D21F97F6 for ; Tue, 21 May 2013 09:48:52 -0700 (PDT) Received: from [128.2.193.239] (minbar.fac.cs.cmu.edu [128.2.193.239]) (authenticated bits=0) by smtp03.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id r4LGmmqV016588 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 21 May 2013 12:48:49 -0400 (EDT) Message-ID: <1369154928.2711.772.camel@minbar.fac.cs.cmu.edu> From: Jeffrey Hutzelman To: Nico Williams Date: Tue, 21 May 2013 12:48:48 -0400 In-Reply-To: <22606_1369111554_r4L4jrrH023245_CAK3OfOiRsqC1RxbU96OGzOUj0=UEcQbXNKPrhBAgYyybQDHD_Q@mail.gmail.com> References: <44302EA3-1CB6-4F9A-A6B4-25F5FCDBCC0A@tycho.ncsc.mil> <22606_1369111554_r4L4jrrH023245_CAK3OfOiRsqC1RxbU96OGzOUj0=UEcQbXNKPrhBAgYyybQDHD_Q@mail.gmail.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 X-Scanned-By: mimedefang-cmuscs on 128.2.217.198 Cc: kitten@ietf.org, Sam Hartman , jhutz@cmu.edu Subject: Re: [kitten] Comments on draft-ietf-kitten-aes-cts-hmac-sha2-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 16:48:58 -0000 On Mon, 2013-05-20 at 23:45 -0500, Nico Williams wrote: > I don't know why the current document avoids confounding, not even > whether it does so deliberately or by accident -- the topic is not > addressed. Section 1 addresses differences from aes-cts-hmac-sha-1, > but does not cover this one; it should. This is actually a problem. Enctype design should be conservative; if we're not going to have a confounder, I want to know why. -- Jeff From kwburgi@tycho.ncsc.mil Tue May 21 10:02:14 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03EA521F967D for ; Tue, 21 May 2013 10:02:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.499 X-Spam-Level: X-Spam-Status: No, score=-10.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lGJGxqGJ+vur for ; Tue, 21 May 2013 10:02:09 -0700 (PDT) Received: from nsa.gov (emvm-gh1-uea09.nsa.gov [63.239.67.10]) by ietfa.amsl.com (Postfix) with ESMTP id D6EAD21F95EE for ; Tue, 21 May 2013 10:02:08 -0700 (PDT) X-TM-IMSS-Message-ID: <277951fa00091841@nsa.gov> Received: from tarius.tycho.ncsc.mil ([144.51.31.2]) by nsa.gov ([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1) id 277951fa00091841 ; Tue, 21 May 2013 13:05:04 -0400 Received: from rd6um-58422h.infosec.tycho.ncsc.mil (rd6um-58422h [192.168.26.151]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id r4LH23gl024661; Tue, 21 May 2013 13:02:03 -0400 Message-Id: <5F29C375-8261-41B2-B188-1938C6201ABD@tycho.ncsc.mil> From: Kelley Burgin To: Jeffrey Hutzelman In-Reply-To: <1369154928.2711.772.camel@minbar.fac.cs.cmu.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 21 May 2013 13:05:51 -0400 References: <44302EA3-1CB6-4F9A-A6B4-25F5FCDBCC0A@tycho.ncsc.mil> <22606_1369111554_r4L4jrrH023245_CAK3OfOiRsqC1RxbU96OGzOUj0=UEcQbXNKPrhBAgYyybQDHD_Q@mail.gmail.com> <1369154928.2711.772.camel@minbar.fac.cs.cmu.edu> X-Mailer: Apple Mail (2.936) Cc: kitten@ietf.org, Sam Hartman Subject: Re: [kitten] Comments on draft-ietf-kitten-aes-cts-hmac-sha2-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 17:02:14 -0000 Sorry - the reason was buried in the previous email: In general, we want to 1. encrypt-then-mac, 2. include the IV directly in the MAC computation (so the MAC value H is different for the same output of the encryption operation C) and 3. on the receiving end check the MAC before decryption (to save decrypting a long message only to find out later that the MAC doesn't verify). I'm probably fine with a scheme that doesn't do the last two in short- plaintext cases (like Tom's and Nico's). However, to achieve all three, the nonce needs to be sent as part of the ciphertext. Also, we have coordinated, to the extent possible (the intended applications there don't have a problem with PKCS#5 padding), with draft-mcgrew-aead-aes-cbc-hmac-sha2 Kelley On May 21, 2013, at 12:48 PM, Jeffrey Hutzelman wrote: > On Mon, 2013-05-20 at 23:45 -0500, Nico Williams wrote: > >> I don't know why the current document avoids confounding, not even >> whether it does so deliberately or by accident -- the topic is not >> addressed. Section 1 addresses differences from aes-cts-hmac-sha-1, >> but does not cover this one; it should. > > This is actually a problem. Enctype design should be conservative; if > we're not going to have a confounder, I want to know why. > > -- Jeff > > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten From jhutz@cmu.edu Tue May 21 10:13:54 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6D1721F97D3 for ; Tue, 21 May 2013 10:13:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BbQGwpuBFrdI for ; Tue, 21 May 2013 10:13:48 -0700 (PDT) Received: from smtp03.srv.cs.cmu.edu (SMTP03.SRV.CS.CMU.EDU [128.2.217.198]) by ietfa.amsl.com (Postfix) with ESMTP id DE58421F97CC for ; Tue, 21 May 2013 10:13:34 -0700 (PDT) Received: from [128.2.193.239] (minbar.fac.cs.cmu.edu [128.2.193.239]) (authenticated bits=0) by smtp03.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id r4LHDXWA017704 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 21 May 2013 13:13:33 -0400 (EDT) Message-ID: <1369156413.2711.777.camel@minbar.fac.cs.cmu.edu> From: Jeffrey Hutzelman To: Kelley Burgin Date: Tue, 21 May 2013 13:13:33 -0400 In-Reply-To: <25505_1369155737_r4LH2GJT027339_5F29C375-8261-41B2-B188-1938C6201ABD@tycho.ncsc.mil> References: <44302EA3-1CB6-4F9A-A6B4-25F5FCDBCC0A@tycho.ncsc.mil> <22606_1369111554_r4L4jrrH023245_CAK3OfOiRsqC1RxbU96OGzOUj0=UEcQbXNKPrhBAgYyybQDHD_Q@mail.gmail.com> <1369154928.2711.772.camel@minbar.fac.cs.cmu.edu> <25505_1369155737_r4LH2GJT027339_5F29C375-8261-41B2-B188-1938C6201ABD@tycho.ncsc.mil> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 X-Scanned-By: mimedefang-cmuscs on 128.2.217.198 Cc: kitten@ietf.org, Sam Hartman , jhutz@cmu.edu Subject: Re: [kitten] Comments on draft-ietf-kitten-aes-cts-hmac-sha2-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 17:13:55 -0000 On Tue, 2013-05-21 at 13:05 -0400, Kelley Burgin wrote: > Sorry - the reason was buried in the previous email: > > In general, we want to > 1. encrypt-then-mac, > 2. include the IV directly in the MAC computation (so the MAC value H > is different for the same output of the encryption operation C) and > 3. on the receiving end check the MAC before decryption (to save > decrypting a long message only to find out later that the MAC doesn't > verify). OK; none of that explains why you do not prepend a random confounder to the data to be encrypted. I think you need to explain both why there is no confounder and why it is not necessary. -- Jeff From nico@cryptonector.com Tue May 21 10:22:03 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CED921F9355 for ; Tue, 21 May 2013 10:22:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P21B2MM2j+4a for ; Tue, 21 May 2013 10:21:58 -0700 (PDT) Received: from homiemail-a25.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id 209AD21F9350 for ; Tue, 21 May 2013 10:21:57 -0700 (PDT) Received: from homiemail-a25.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTP id C20AE678071 for ; Tue, 21 May 2013 10:21:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=a9MCOjvfwKkAgorSZSQm NoVlzj0=; b=O3ozaNwnuVOXainahC2wLPJ5Wa8U80UccPEiOYByMdLSDwvageCv 2Hs/GyHt/HwCwLf9b2TOsWAcgS7rNuBKBOSGYJMbX4L/euj1HC8mPN/MjWH0TAPC W3dqNFI3mLSbW6iy9KBcAcfDGsmeWbG0A/QC7nmuSe/jMynmEduUhKo= Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTPSA id 646C0678069 for ; Tue, 21 May 2013 10:21:56 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id k13so529721wgh.29 for ; Tue, 21 May 2013 10:21:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=iNrbkySVHO/rjwmCAuQXN0+tBrUem+S8EAzDjNwry7Y=; b=WuZccXIUBWc35LS3MRhRAiQm0BF+iJsQqqKGmiE3TJziI/CO9BpLzXSQFpw8W/fFUi JzPr8dpOd4O4IOEgOG0BQyNTbssaxQcM8dX5QjklL+FbibG4eARiVOCkIcceXmP/ryks 0QdXNCJr6xltnZgk2JOkY+Lj4FdRdCdhP+0SCZ+vDB0FRRcRMpBYUx9uTfa+Qdwb+G83 bjj1XNCd/u2cCMsyhxsTtlHXKmHQGUVcA8WPaC6mDOZPDH+1YfM966i1EIWr3la8pHHc 2danoYOL0cEh6x+OgaTVpPjzVYAOiLGxZCjbxkSi/6pWNhFboZc7xuRYsepCGQ/MBuE/ aJsw== MIME-Version: 1.0 X-Received: by 10.180.39.137 with SMTP id p9mr25473421wik.27.1369156914656; Tue, 21 May 2013 10:21:54 -0700 (PDT) Received: by 10.216.111.132 with HTTP; Tue, 21 May 2013 10:21:54 -0700 (PDT) In-Reply-To: <7E40423E-7040-4AD5-9135-97032369CAC0@tycho.ncsc.mil> References: <44302EA3-1CB6-4F9A-A6B4-25F5FCDBCC0A@tycho.ncsc.mil> <7E40423E-7040-4AD5-9135-97032369CAC0@tycho.ncsc.mil> Date: Tue, 21 May 2013 12:21:54 -0500 Message-ID: From: Nico Williams To: Kelley Burgin Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org, Sam Hartman Subject: Re: [kitten] Comments on draft-ietf-kitten-aes-cts-hmac-sha2-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 17:22:03 -0000 On Tue, May 21, 2013 at 11:18 AM, Kelley Burgin wrote: > Both Tom's and Nico's short-plaintext schemes miss something I'm looking > for: the presence of the IV in the MAC computation. Otherwise the MAC value > H is always the same for a given C (output of the encryption operation). When confounding the ciphertext of the confounder is included in MAC computation. Why is this not sufficient? From hartmans@mit.edu Tue May 21 11:18:14 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0264421F95F1 for ; Tue, 21 May 2013 11:18:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5lQ1oV-uqDP4 for ; Tue, 21 May 2013 11:18:08 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 15D9421F95EC for ; Tue, 21 May 2013 11:18:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 6FE2420608; Tue, 21 May 2013 14:15:06 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1d3evsLRJlKw; Tue, 21 May 2013 14:15:05 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (unknown [10.1.10.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Tue, 21 May 2013 14:15:05 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 51877440B; Tue, 21 May 2013 14:18:02 -0400 (EDT) From: Sam Hartman To: Nico Williams References: <44302EA3-1CB6-4F9A-A6B4-25F5FCDBCC0A@tycho.ncsc.mil> <7E40423E-7040-4AD5-9135-97032369CAC0@tycho.ncsc.mil> Date: Tue, 21 May 2013 14:18:02 -0400 In-Reply-To: (Nico Williams's message of "Tue, 21 May 2013 12:21:54 -0500") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: kitten@ietf.org, Sam Hartman Subject: Re: [kitten] Comments on draft-ietf-kitten-aes-cts-hmac-sha2-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 18:18:14 -0000 >>>>> "Nico" == Nico Williams writes: Nico> On Tue, May 21, 2013 at 11:18 AM, Kelley Burgin wrote: >> Both Tom's and Nico's short-plaintext schemes miss something I'm >> looking for: the presence of the IV in the MAC >> computation. Otherwise the MAC value H is always the same for a >> given C (output of the encryption operation). Nico> When confounding the ciphertext of the confounder is included Nico> in MAC computation. Why is this not sufficient? The rest of the world (non-Kerberos) seems to use explicit IVs that are sent in the clear just fine. The only area I'd be concerned about is to make sure an attacker does not gain an advantage if they know the cipherstate between two messages. it seems like using an explicit IV instead of a confounder is fairly conservative cryptographic practice at this point. From nico@cryptonector.com Tue May 21 11:47:11 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18C9D21F95D7 for ; Tue, 21 May 2013 11:47:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SN3qjVK8ifvh for ; Tue, 21 May 2013 11:47:06 -0700 (PDT) Received: from homiemail-a24.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id 1FB6421F958D for ; Tue, 21 May 2013 11:47:06 -0700 (PDT) Received: from homiemail-a24.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTP id 9882A2C806C for ; Tue, 21 May 2013 11:46:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=U14yheeaPw4TT0t4quUu iRgRjAw=; b=GNzBBUDbLqugvnK3BoN1DhD0sUdoq+wOhYHi92/XrQ1AfZ1ziK1k V/ufTQ4WshMVMzLBwistH78+agcZyCmwGZdOzvkbfsrxODaJdA3Xv4dBxVPE8Lke HzE48+JX4NaZdwbOuZydQ+ZtJT86F/B3ODqK8kpYkON23jRld6ttjc0= Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTPSA id 522152C806B for ; Tue, 21 May 2013 11:45:48 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id hr14so569107wib.16 for ; Tue, 21 May 2013 11:45:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8M7DeQqsUNajfnjwYZ1mJl3zkfNelbWOLDqmQIIufWg=; b=IqIL9q/h3Dr3aq0fXk498P52vcJLyTbWu6QDAaqgTlMVsdex9zmX7qNfoId/u3aoI7 nzDaqjsLAzRRMdc4LtO6SUXPaR9qNS0apy0kGgfw88dzy3WvRBH2nnpzSxWQhKikIbvb cECR+JUghU6L8tknjhQxw5TwCDc+OqbQj0S8GMhgmgJsrzkp00akbgpGZHd6+UJbdSUh fdLu6sWMrwszG4n+2Ojokm6P+q6wzChHbexCT2F3jxhOj1aqZ+/27DdwN3s37ifkSbTw umuUKe4dCRqLf+UzXWO8G2ibAM2qtnOV5TCkLyVIEWKn5xiLgbw65Xj41nMrFzH6KaIn u+lg== MIME-Version: 1.0 X-Received: by 10.180.210.225 with SMTP id mx1mr26617961wic.15.1369161945288; Tue, 21 May 2013 11:45:45 -0700 (PDT) Received: by 10.216.111.132 with HTTP; Tue, 21 May 2013 11:45:44 -0700 (PDT) In-Reply-To: References: <44302EA3-1CB6-4F9A-A6B4-25F5FCDBCC0A@tycho.ncsc.mil> <7E40423E-7040-4AD5-9135-97032369CAC0@tycho.ncsc.mil> Date: Tue, 21 May 2013 13:45:44 -0500 Message-ID: From: Nico Williams To: Sam Hartman Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org Subject: Re: [kitten] Comments on draft-ietf-kitten-aes-cts-hmac-sha2-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 18:47:11 -0000 On Tue, May 21, 2013 at 1:18 PM, Sam Hartman wrote: > Nico> When confounding the ciphertext of the confounder is included > Nico> in MAC computation. Why is this not sufficient? > > The rest of the world (non-Kerberos) seems to use explicit IVs that are > sent in the clear just fine. The only area I'd be concerned about is to > make sure an attacker does not gain an advantage if they know the > cipherstate between two messages. That's not responsive. > it seems like using an explicit IV instead of a confounder is fairly > conservative cryptographic practice at this point. But so is confounding. Or, if confounding is not secure, maybe we should find out. Nico -- From nico@cryptonector.com Tue May 21 11:51:43 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 970B321F9588 for ; Tue, 21 May 2013 11:51:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.72 X-Spam-Level: X-Spam-Status: No, score=-1.72 tagged_above=-999 required=5 tests=[AWL=0.257, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5HTdF5onI2-O for ; Tue, 21 May 2013 11:51:36 -0700 (PDT) Received: from homiemail-a90.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id 0089B21F9540 for ; Tue, 21 May 2013 11:51:33 -0700 (PDT) Received: from homiemail-a90.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a90.g.dreamhost.com (Postfix) with ESMTP id 1746F2AC06E for ; Tue, 21 May 2013 11:51:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=YU4dWrY287eV47MWHxdY iEEHRT0=; b=D8e7ethleyoyUu+wFMuA0LhT/mmaKY3hqQWzH6AWe8jzEh8tvonT +egxo9mxwRwe2+isBAkWj4YejL1eAmXonIGkO9ZGLO1/L4cwiVGPI7G3UaXUecTB JvnIdYsAxYyjHpDmvAOdnA6+VBGSYsuKsJxox3qqbC4Vhf+rsrFTukE= Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a90.g.dreamhost.com (Postfix) with ESMTPSA id 4C0FD2AC05D for ; Tue, 21 May 2013 11:51:31 -0700 (PDT) Received: by mail-wi0-f180.google.com with SMTP id hn14so572033wib.13 for ; Tue, 21 May 2013 11:51:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=m5kmtwGsawE9ROuwybpjbz9+0aApgwarWjoGgXEKuTA=; b=ap4ZFld64xC8oEmOmUdmK68k+EGzKouvJcPma+VN2hpph2Q7VwRbgdZBwAgbGgE1aj Vf3RpnF7FxRgmLLkDvFFuXCTcx3N0+2gyzJG5lvhlli54WnZqCqz6+e2GiU0Q7tiqZPy XNKTaWU3y6LxJx+AlGgDCcCkhtIujETkLOrTvegXDwlB3JijgSSdB3EtcU4jdsk7SxYA Cbq2v2NIqNuhc8MqZBsUvEI/p4QPpL8D4dPusYGkHU6hWrZbIvpia+uuW3OPR7ClociB HcfA5mjWKGtv3KJZT6z7oTi9b9ko1QcH+aFLLp7ls5pG19aeAwcEu/S9ABZo5cj0uJRA lD8Q== MIME-Version: 1.0 X-Received: by 10.181.13.229 with SMTP id fb5mr7719428wid.16.1369162290459; Tue, 21 May 2013 11:51:30 -0700 (PDT) Received: by 10.216.111.132 with HTTP; Tue, 21 May 2013 11:51:30 -0700 (PDT) In-Reply-To: <5F29C375-8261-41B2-B188-1938C6201ABD@tycho.ncsc.mil> References: <44302EA3-1CB6-4F9A-A6B4-25F5FCDBCC0A@tycho.ncsc.mil> <22606_1369111554_r4L4jrrH023245_CAK3OfOiRsqC1RxbU96OGzOUj0=UEcQbXNKPrhBAgYyybQDHD_Q@mail.gmail.com> <1369154928.2711.772.camel@minbar.fac.cs.cmu.edu> <5F29C375-8261-41B2-B188-1938C6201ABD@tycho.ncsc.mil> Date: Tue, 21 May 2013 13:51:30 -0500 Message-ID: From: Nico Williams To: Kelley Burgin Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org, Sam Hartman , Jeffrey Hutzelman Subject: Re: [kitten] Comments on draft-ietf-kitten-aes-cts-hmac-sha2-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 18:51:43 -0000 On Tue, May 21, 2013 at 12:05 PM, Kelley Burgin wrote: > In general, we want to > 1. encrypt-then-mac, Agreed. > 2. include the IV directly in the MAC computation (so the MAC value H is > different for the same output of the encryption operation C) and Note that this is true with confounding anyways: every ciphertext of the same plaintext (as provided by the application) is randomized because the plaintext prepended with a nonce. If there's something wrong with confounded encrypt-then-MAC (and verify-then-decrypt) we should know, since we rely on confounding in Kerberos today. > 3. on the receiving end check the MAC before decryption (to save decrypting > a long message only to find out later that the MAC doesn't verify). And to avoid padding attacks. (It helps to have no padding, of course.) > > I'm probably fine with a scheme that doesn't do the last two in > short-plaintext cases (like Tom's and Nico's). However, to achieve all > three, the nonce needs to be sent as part of the ciphertext. No, my scheme gets you all three. Confounding does not preclude any of (1), (2), nor (3). Nico -- From hartmans@mit.edu Tue May 21 11:56:53 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2502D21F96E0 for ; Tue, 21 May 2013 11:56:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1TkVeupt9NOb for ; Tue, 21 May 2013 11:56:47 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 6469921F9603 for ; Tue, 21 May 2013 11:56:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 9B27E2060D; Tue, 21 May 2013 14:53:49 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fcnn22VxhzTJ; Tue, 21 May 2013 14:53:49 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (unknown [10.1.10.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Tue, 21 May 2013 14:53:49 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 6CF89440B; Tue, 21 May 2013 14:56:45 -0400 (EDT) From: Sam Hartman To: Nico Williams References: <44302EA3-1CB6-4F9A-A6B4-25F5FCDBCC0A@tycho.ncsc.mil> <22606_1369111554_r4L4jrrH023245_CAK3OfOiRsqC1RxbU96OGzOUj0=UEcQbXNKPrhBAgYyybQDHD_Q@mail.gmail.com> <1369154928.2711.772.camel@minbar.fac.cs.cmu.edu> <5F29C375-8261-41B2-B188-1938C6201ABD@tycho.ncsc.mil> Date: Tue, 21 May 2013 14:56:45 -0400 In-Reply-To: (Nico Williams's message of "Tue, 21 May 2013 13:51:30 -0500") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: kitten@ietf.org, Sam Hartman , Jeffrey Hutzelman Subject: Re: [kitten] Comments on draft-ietf-kitten-aes-cts-hmac-sha2-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 18:56:53 -0000 >>>>> "Nico" == Nico Williams writes: Nico> Note that this is true with confounding anyways: every Nico> ciphertext of the same plaintext (as provided by the Nico> application) is randomized because the plaintext prepended Nico> with a nonce. Note that having a nonce including in the IV also gets you this. It's quite important that two encryptions of the same plaintext result in different ciphertexts. From hotz@jpl.nasa.gov Tue May 21 11:59:37 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D3F221F8D31 for ; Tue, 21 May 2013 11:59:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jf2sA1tQZVTX for ; Tue, 21 May 2013 11:59:31 -0700 (PDT) Received: from mail.jpl.nasa.gov (smtp.jpl.nasa.gov [128.149.139.105]) by ietfa.amsl.com (Postfix) with ESMTP id 6972921F87D1 for ; Tue, 21 May 2013 11:59:30 -0700 (PDT) Received: from laphotz.jpl.nasa.gov (laphotz.jpl.nasa.gov [128.149.133.44]) (authenticated (0 bits)) by smtp.jpl.nasa.gov (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r4LIxNZe020600 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO); Tue, 21 May 2013 11:59:24 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: "Henry B. Hotz" In-Reply-To: Date: Tue, 21 May 2013 11:59:29 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Nico Williams X-Mailer: Apple Mail (2.1503) X-Source-Sender: hotz@jpl.nasa.gov X-AUTH: Authorized Cc: kitten@ietf.org, Sam Hartman Subject: Re: [kitten] OT: ktutil and x-realm keys (Re: Comments on draft-ietf-kitten-aes-cts-hmac-sha2-00) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 18:59:37 -0000 On May 20, 2013, at 5:04 PM, Nico Williams = wrote: > On Mon, May 20, 2013 at 6:46 PM, Henry B. Hotz = wrote: >> On May 16, 2013, at 9:36 AM, Greg Hudson wrote: >>> * Cross-realm TGTs are currently managed by entering the same = password >>> at two KDCs to get the same keys. If each KDC uses a random salt, = they >>> won't have the same keys. >>=20 >> Obviously off-topic, but I've advocated for a "keytab import" = administrative function as a way to avoid retyping passwords in this = case. Yeah, yeah, "write it yourself, it's open-source", I know. >=20 > I don't think that's the best way to implement this. As long as we > must have password-based x-realm keys But that's the point. They shouldn't be password-based at all. The = string-to-key function isn't needed to make the tgs exchanges work. All = implementations can already generate random keys. All implementations = can already *export* keytab files independent of the password. Just add = the inverse operation. See slide 16 of my 2007 AFS BP workshop presentation for how it works = for Heimdal<->Heimdal cross-realm. (I neglected to say you start with = an "add -r" or two.) > the way it should work is that > one admin creates an x-realm princ on on realm, then the other realm's > admin does an AS exchange to fetch the salt (and other s2kparams) and > validate the password they've been told on the phone/whatever, then > the key gets added to that realm. This is, also, how password-based > keys should be added to keytabs (to fetch the salt and other > s2kparams). >=20 > But this is off-topic, and also off-topic: we really need > password-authenticated DH-exchanged x-realm keys and PKI-authenticated > DH-exchanged x-realm keys. I.e., PKCROSS. >=20 > Nico > -- ------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu From tlyu@mit.edu Tue May 21 12:53:09 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF02411E811B for ; Tue, 21 May 2013 12:53:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3U6KT+8kUcMF for ; Tue, 21 May 2013 12:53:03 -0700 (PDT) Received: from dmz-mailsec-scanner-3.mit.edu (DMZ-MAILSEC-SCANNER-3.MIT.EDU [18.9.25.14]) by ietfa.amsl.com (Postfix) with ESMTP id 12EF011E80FB for ; Tue, 21 May 2013 12:53:02 -0700 (PDT) X-AuditID: 1209190e-b7f4f6d000005142-cf-519bd09e0dc3 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id 48.15.20802.E90DB915; Tue, 21 May 2013 15:53:02 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id r4LJqxVG003870; Tue, 21 May 2013 15:53:00 -0400 Received: from cathode-dark-space.mit.edu (CATHODE-DARK-SPACE.MIT.EDU [18.18.1.96]) (authenticated bits=56) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id r4LJquxc022451 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 21 May 2013 15:52:58 -0400 Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id r4LJqu1Q016231; Tue, 21 May 2013 15:52:56 -0400 (EDT) To: Kelley Burgin References: <44302EA3-1CB6-4F9A-A6B4-25F5FCDBCC0A@tycho.ncsc.mil> <7E40423E-7040-4AD5-9135-97032369CAC0@tycho.ncsc.mil> From: Tom Yu Date: Tue, 21 May 2013 15:52:56 -0400 In-Reply-To: <7E40423E-7040-4AD5-9135-97032369CAC0@tycho.ncsc.mil> (Kelley Burgin's message of "Tue, 21 May 2013 12:18:55 -0400") Message-ID: Lines: 150 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBKsWRmVeSWpSXmKPExsUixCmqrDvvwuxAg3eTJSy+tj1gszi6eRWL xbyGDIvTt54zW5y6doTNgdXj5alzjB5Llvxk8njbcJXdY+XU0+weW5v/MQawRnHZpKTmZJal FunbJXBl7NsUXdCnXnH48RGWBsZpcl2MnBwSAiYSUy6sY4OwxSQu3FsPZHNxCAnsY5RonnCb BcLZyCjx/tEmRgjnHJPEmZevmCCcLkaJHxv2M4P0iwhoSVx9OIcZJMEMkmj/t5UFJCEs4CHx cOUzqMHdLBJHF69g72Lk4GATkAayy0BqWARUJf40vmAHqeEUaGSUuHvqIDtIglfAQqJ/4n2w QTwCXBJt85YzQ8QFJU7OfAIWZwbafOPfS6YJjIKzkKRmIUktYGRaxSibklulm5uYmVOcmqxb nJyYl5dapGusl5tZopeaUrqJERzoknw7GL8eVDrEKMDBqMTD+6B2dqAQa2JZcWXuIUZJDiYl UV6180AhvqT8lMqMxOKM+KLSnNTiQ4wSHMxKIrzznYByvCmJlVWpRfkwKWkOFiVx3ispN/2F BNITS1KzU1MLUotgsjIcHEoSvOtBhgoWpaanVqRl5pQgpJk4OEGG8wANfw1Sw1tckJhbnJkO kT/FqMux+fzkd4xCLHn5ealS4rz7QYoEQIoySvPg5sAS1CtGcaC3hHnPgVTxAJMb3KRXQEuY gJZst5wJsqQkESEl1cCYYtnKVZ7K9lC3xNeptMBU+r7R2Zh7P30VtsTOO3v+otSUDV+qDLS/ LpvMKeL5mbtZ5IfXEX/ZM/PmfFCavrlMns2+XLuzoCHh4IP9DspuIVt9cyqv6wepfo+9V57+ Na+BvdZKZOuak9LlVy3i91zSWSTOZHwoRLJEwzm/iD/bfPVt9oPthUosxRmJhlrMRcWJAI01 0jgrAwAA Cc: kitten@ietf.org, Sam Hartman Subject: Re: [kitten] Comments on draft-ietf-kitten-aes-cts-hmac-sha2-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 19:53:09 -0000 Kelley Burgin writes: > Both Tom's and Nico's short-plaintext schemes miss something I'm > looking for: the presence of the IV in the MAC computation. Otherwise > the MAC value H is always the same for a given C (output of the > encryption operation). I think both my proposal and Nico's use the nonce rather than the IV, but they should have the same amount of entropy. That should be sufficient to prevent multiple encryptions of the same plaintext from producing identical ciphertext. > In general, we want to encrypt-then-mac, include the IV directly in > the MAC computation and on the receiving end check the MAC before > decryption (to save decrypting a long message only to find out later > that the MAC doesn't verify). I'm probably fine with a scheme that > doesn't do the last two in short-plaintext cases (like Tom's and > Nico's). However, to achieve all three, the nonce needs to be sent as > part of the ciphertext. > > Here are my comments on the two proposed short-plaintext schemes: > > In Tom's scheme for short-plaintext cases, it seems that duplicate > information is being sent, if I understand correctly: isn't C1 a > subset of the bits of N1? If so, it would be useful to include part of > the IV in the MAC computation instead of C1 to diversify the MAC > values for a given C. I think I chose variable names poorly; they are not redundant. C1 is the the first plen bytes of the nonce N. N1 is the single-block output of Enc-CBC(Ke, plaintext | nullpad, IV) and does not contain any plaintext bits of the nonce. If the nonce N is random, it provides just as much randomization of the ciphertext as the IV would (assuming they're independent of the cipherstate). > Tom's: > [ > plen = len(plaintext) > if plen < blocksize: > C = Enc-CBC(Ke, plaintext | nullpad, IV) > N1 = C[1..blocksize] > C1 = N[1..plen] > H = HMAC(Ki, N1 | C1) > ciphertext = N1 | C1 | H[1..h] > ] > > could change to (note the receiver has to decrypt first to recover the > IV, then verify the MAC) > > [ > plen = len(plaintext) > if plen < blocksize: > C = Enc-CBC(Ke, plaintext | nullpad, IV) > IV* = IV[1..plen] <-- don't truncate N1, use IV instead > H = HMAC(Ki, C | IV*) > ciphertext = C | IV* | H[1..h] > ] That's not too different from the following: plen = len(plaintext) if plen < blocksize: C = Enc-CBC(Ke, plaintext | nullpad, IV) N* = N[1..plen] H = HMAC(Ki, C | N*) ciphertext = C | N* | H[1..h] It's mostly a question of whether you send the truncated IV directly or whether you send the truncated nonce instead. > Nico's could also be modified to include the IV in the MAC > computation, without expanding the ciphertext: > > Nico's: > [ > C = E(Ke, N | plaintext, cipherstate) > H = HMAC(Ki, C) > ciphertext = C, H Nico's version includes the nonce N, which the current document specifies to be random. > and corresponding change to the decrypt side: > > (C, H) = ciphertext > if (H != HMAC(Ki, C)[1..h]) > stop, report error > IV = cipherstate > (N, P) = D(Ke, C, IV) > cipherState = N > ] > > could change to > > [ > C = E(Ke, N | plaintext, cipherstate) > H = HMAC(Ki, N | C) <-- added nonce here > ciphertext = C, H > > decrypt > > (C, H) = ciphertext > IV = cipherstate <-- decrypt first to recover the nonce, then > check MAC > (N, P) = D(Ke, C, IV) > if (H != HMAC(Ki, N | C)[1..h]) > stop, report error > cipherState = N > ] > > > > On May 21, 2013, at 12:45 AM, Nico Williams wrote: > >> On Mon, May 20, 2013 at 10:58 PM, Tom Yu wrote: >>> Nico Williams writes: >>>> On Mon, May 20, 2013 at 7:21 PM, Tom Yu wrote: >>>>> Nico Williams writes: >>>>>> I don't see the problem. In the short-plaintext case we'd have: >>>>>> >>>>>> C = E(Ke, N | plaintext, cipherstate) >>>>>> H = HMAC(Ki, C) >>>>>> ciphertext = C >>>>> >>>>> That's not quite right, unless you're redefining E. If E is >>>>> SP800-38A+ "CBC-CS3", it doesn't really work unless >>>>> len(plaintext) is >>>>> greater than the blocksize. We can still send a truncated nonce >>>>> instead of a truncated IV, because we can recover the entire IV on >>>>> decryption. >>>> >>>> Here E() operates on a plaintext 16-31 bytes long: E | P. There's >>>> no problem. >>> >>> I think you mean the plaintext is N | plaintext. It sounds like >> >> That's what I wrote, yes :) >> >>> you're making the short-plaintext encryption change to using a >>> confounder, which the current document seems to deliberately avoid. >> >> I don't know why the current document avoids confounding, not even >> whether it does so deliberately or by accident -- the topic is not >> addressed. Section 1 addresses differences from aes-cts-hmac-sha-1, >> but does not cover this one; it should. >> >> Nico >> -- From nico@cryptonector.com Tue May 21 13:06:27 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B1D611E810D for ; Tue, 21 May 2013 13:06:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ciWOYXxZ95y for ; Tue, 21 May 2013 13:06:22 -0700 (PDT) Received: from homiemail-a31.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id 7593C11E8104 for ; Tue, 21 May 2013 13:06:22 -0700 (PDT) Received: from homiemail-a31.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTP id 1431D20205A for ; Tue, 21 May 2013 13:05:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=aXpX4xM3V4obOb5fw+nc zBb5cik=; b=utvJCgR+JEyagD5yI3VVKvi9d3lFgsY/L+jfMv3JT++gYsv7FCmf +X5vf+b8yLfEm/bBsHTaI+TqiiwP5eUuyKrwfwMJXhusDoJdp8pxKgkKesTopb6v aBxk+HpSekFQWgts16aF5X1cJl8pc4wbtH5OuOm5YPKBqF5dqvK6VEA= Received: from mail-we0-f170.google.com (mail-we0-f170.google.com [74.125.82.170]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTPSA id 8414120205C for ; Tue, 21 May 2013 13:05:19 -0700 (PDT) Received: by mail-we0-f170.google.com with SMTP id u59so24212wes.15 for ; Tue, 21 May 2013 13:05:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=MHPSg6QnnwoECdRZDf0KXdazHWC73w2zpQ1dwY++Sm0=; b=F+JZx5Tqm5NR1E3BB/OR3dvVvJq95IRhdUGt3F41s6Nocd5ENOE373hcnt7hPfA20U mGIA5o8Fci+vX4VyGMlPyG/0puQX6DMMDs+t+WS2ZzBQhYVnu5IwqcyuPda/tdzqmdnc uzPOmZz3jozckMbXV7lx6EKM494zzpOzCiZXjwfv1PVmt3CFlTcWmR4rfbzHvypQGSHi VNZ93ZxSRfn3OJlio7PZ9FG+RASvRrpTG8PW/3ffcu2Y3FKgv4agfA2gYrtSr02+dXmW IMLM2XGtbYwhqWqvTvFEI+vhHuc1dkcW8HqzOOZF1+9CV2/EpNd31eHWFypolmB3G0U6 dyhA== MIME-Version: 1.0 X-Received: by 10.180.39.137 with SMTP id p9mr26715613wik.27.1369166718108; Tue, 21 May 2013 13:05:18 -0700 (PDT) Received: by 10.216.111.132 with HTTP; Tue, 21 May 2013 13:05:17 -0700 (PDT) In-Reply-To: References: <44302EA3-1CB6-4F9A-A6B4-25F5FCDBCC0A@tycho.ncsc.mil> <22606_1369111554_r4L4jrrH023245_CAK3OfOiRsqC1RxbU96OGzOUj0=UEcQbXNKPrhBAgYyybQDHD_Q@mail.gmail.com> <1369154928.2711.772.camel@minbar.fac.cs.cmu.edu> <5F29C375-8261-41B2-B188-1938C6201ABD@tycho.ncsc.mil> Date: Tue, 21 May 2013 15:05:17 -0500 Message-ID: From: Nico Williams To: Sam Hartman Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org, Jeffrey Hutzelman Subject: Re: [kitten] Comments on draft-ietf-kitten-aes-cts-hmac-sha2-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 20:06:27 -0000 On Tue, May 21, 2013 at 1:56 PM, Sam Hartman wrote: >>>>>> "Nico" == Nico Williams writes: > > Nico> Note that this is true with confounding anyways: every > Nico> ciphertext of the same plaintext (as provided by the > Nico> application) is randomized because the plaintext prepended > Nico> with a nonce. > > Note that having a nonce including in the IV also gets you this. It's > quite important that two encryptions of the same plaintext result in > different ciphertexts. There's no disagreement as to that. I'm happy to not confound. But while you can tell me that not confounding is fine till your face turns blue, that doesn't address the short plaintext issue. Nor does it address the need for some text explaining the departure from Kerberos tradition -- I don't think strong justification is needed, mind you, as I'm sold on it (at least for plaintexts 16 bytes or longer). Nico -- From jhutz@cmu.edu Tue May 21 13:40:08 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ECBB21F92CB for ; Tue, 21 May 2013 13:40:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H8+gEgJ-xa4u for ; Tue, 21 May 2013 13:40:02 -0700 (PDT) Received: from smtp02.srv.cs.cmu.edu (SMTP02.SRV.CS.CMU.EDU [128.2.217.197]) by ietfa.amsl.com (Postfix) with ESMTP id CE66421F968E for ; Tue, 21 May 2013 13:40:01 -0700 (PDT) Received: from [128.2.193.239] (minbar.fac.cs.cmu.edu [128.2.193.239]) (authenticated bits=0) by smtp02.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id r4LKdwHb025325 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 21 May 2013 16:39:58 -0400 (EDT) Message-ID: <1369168798.2711.787.camel@minbar.fac.cs.cmu.edu> From: Jeffrey Hutzelman To: Sam Hartman Date: Tue, 21 May 2013 16:39:58 -0400 In-Reply-To: <1223_1369160296_r4LIIFoA001408_tsl8v38urhh.fsf@mit.edu> References: <44302EA3-1CB6-4F9A-A6B4-25F5FCDBCC0A@tycho.ncsc.mil> <7E40423E-7040-4AD5-9135-97032369CAC0@tycho.ncsc.mil> <1223_1369160296_r4LIIFoA001408_tsl8v38urhh.fsf@mit.edu> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 X-Scanned-By: mimedefang-cmuscs on 128.2.217.197 Cc: kitten@ietf.org, jhutz@cmu.edu Subject: Re: [kitten] Comments on draft-ietf-kitten-aes-cts-hmac-sha2-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 20:40:08 -0000 On Tue, 2013-05-21 at 14:18 -0400, Sam Hartman wrote: > The rest of the world (non-Kerberos) seems to use explicit IVs that are > sent in the clear just fine. The only area I'd be concerned about is to > make sure an attacker does not gain an advantage if they know the > cipherstate between two messages. > > it seems like using an explicit IV instead of a confounder is fairly > conservative cryptographic practice at this point. You seem to be replying to Nico with an attempt to answer my question, or at least part of it. When I said we should be conservative, I meant that departures from existing designs should not be arbitrary or gratuitous. There needs to be a reason for the change, and there needs to be some confidence that the change does not introduce a new problem. I think we can agree that introducing an explicit IV does not create a worse situation than the fixed IV used in existing enctypes. And I could come up with some reasons for doing so, but I'd rather hear the actual reasons. On the other hand, I am very nervous about omitting the random secret confounder used by existing enctypes. So far, I have seen neither an indication of why this is necessary or why introducing a public IV makes a secret confounder unnecessary. -- Jeff From tlyu@mit.edu Tue May 21 13:45:39 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29EED11E8109 for ; Tue, 21 May 2013 13:45:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.149 X-Spam-Level: X-Spam-Status: No, score=-103.149 tagged_above=-999 required=5 tests=[AWL=0.450, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rzzWSQQhJZlN for ; Tue, 21 May 2013 13:45:32 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (DMZ-MAILSEC-SCANNER-2.MIT.EDU [18.9.25.13]) by ietfa.amsl.com (Postfix) with ESMTP id 1ED0C11E811A for ; Tue, 21 May 2013 13:45:32 -0700 (PDT) X-AuditID: 1209190d-b7f716d000005557-23-519bdcebfeab Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id E8.90.21847.BECDB915; Tue, 21 May 2013 16:45:31 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id r4LKjTNd018310; Tue, 21 May 2013 16:45:30 -0400 Received: from cathode-dark-space.mit.edu (CATHODE-DARK-SPACE.MIT.EDU [18.18.1.96]) (authenticated bits=56) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id r4LKjRA0014486 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 21 May 2013 16:45:28 -0400 Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id r4LKjR05016364; Tue, 21 May 2013 16:45:27 -0400 (EDT) To: Nico Williams References: <44302EA3-1CB6-4F9A-A6B4-25F5FCDBCC0A@tycho.ncsc.mil> <7E40423E-7040-4AD5-9135-97032369CAC0@tycho.ncsc.mil> From: Tom Yu Date: Tue, 21 May 2013 16:45:26 -0400 In-Reply-To: (Nico Williams's message of "Tue, 21 May 2013 13:45:44 -0500") Message-ID: Lines: 21 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplleLIzCtJLcpLzFFi42IRYrdT0X19Z3agwa6V4hZf2x6wWRzdvIrF Yl5DhsXpW8+ZLU5dO8LmwOrx8tQ5Ro8lS34yebxtuMrusXLqaXaPrc3/GANYo7hsUlJzMstS i/TtErgynr0/wFLQwFEx5d9j5gbGc2xdjJwcEgImErd7b7NC2GISF+6tB4pzcQgJ7GOUuDrv JhOEs5FR4tiDeawQzjkmibcTutghnC5GiWVfd4D1iwhoSlyftxSsn1lgCqPE3aXbWEASwgIe Eg9XPoMavJVV4uyBq0AJDg42AWmJo4vLQGpYBFQlml50soDUcApMYJTYsaOJHSTBK2Ah8eDn Z7BBPAKcEs0/17NCxAUlTs58AhZnFtCSuPHvJdMERsFZSFKzkKQWMDKtYpRNya3SzU3MzClO TdYtTk7My0st0jXSy80s0UtNKd3ECAp1TkneHYzvDiodYhTgYFTi4X1QOztQiDWxrLgy9xCj JAeTkijv1dtAIb6k/JTKjMTijPii0pzU4kOMEhzMSiK8hteAcrwpiZVVqUX5MClpDhYlcd4r KTf9hQTSE0tSs1NTC1KLYLIyHBxKErxLQIYKFqWmp1akZeaUIKSZODhBhvMADX8MUsNbXJCY W5yZDpE/xagoJc67CiQhAJLIKM2D64WloleM4kCvCPOeBKniAaYxuO5XQIOZgAZvt5wJMrgk ESEl1cAYMvvDI+H/bKUq76ZWxBnKmMfW3jGL2yWYs7T98FeDDYtbD69LdTu83TsjNi2ZcdLH kOe/l1X428+TvmjyukrxV+vqmcZ/Fk6vnFPvVengWH3u7LrggGUVN5XK+S9pmLYfCztZ5/W2 IXlyYfah10kx/ExbJ2okrd3/SNxqbWPIVYuzZyfn285VYinOSDTUYi4qTgQAVU+VMiADAAA= Cc: kitten@ietf.org, Sam Hartman Subject: Re: [kitten] Comments on draft-ietf-kitten-aes-cts-hmac-sha2-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 20:45:39 -0000 Nico Williams writes: >> it seems like using an explicit IV instead of a confounder is fairly >> conservative cryptographic practice at this point. > > But so is confounding. Or, if confounding is not secure, maybe we > should find out. I think CBC with explicit random IV is better analyzed in the literature. Encrypt-then-MAC is provably IND-CCA and INT-CTXT secure given some reasonable assumptions about the MAC and the encryption scheme. (Bellare and Namprempre, "Authenticated Encryption: Relations among notions and analysis of the generic composition paradigm", 2000.) The "simplified profile" in RFC 3961 (prepend confounder, then independently MAC and CBC-encrypt with zero IV) is provably IND-CCA and INT-CTXT secure. See Boldyreva and Kumar, "Provable-Security Analysis of Authenticated Encryption in Kerberos", 2007. Among other things, it aruges that CBC encryption with zero IV and random confounder is at least as secure as CBC encryption with random IV. From tlyu@mit.edu Tue May 21 15:13:33 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2191C1F0D3A for ; Tue, 21 May 2013 15:13:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.239 X-Spam-Level: X-Spam-Status: No, score=-103.239 tagged_above=-999 required=5 tests=[AWL=0.360, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Ms6rCSwCCDj for ; Tue, 21 May 2013 15:13:26 -0700 (PDT) Received: from dmz-mailsec-scanner-1.mit.edu (DMZ-MAILSEC-SCANNER-1.MIT.EDU [18.9.25.12]) by ietfa.amsl.com (Postfix) with ESMTP id 7270B1F0D40 for ; Tue, 21 May 2013 15:13:25 -0700 (PDT) X-AuditID: 1209190c-b7f566d000004c69-62-519bf184c2ac Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 3F.CD.19561.481FB915; Tue, 21 May 2013 18:13:24 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id r4LMDNQg021256; Tue, 21 May 2013 18:13:24 -0400 Received: from cathode-dark-space.mit.edu (CATHODE-DARK-SPACE.MIT.EDU [18.18.1.96]) (authenticated bits=56) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id r4LMDL43023431 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 21 May 2013 18:13:23 -0400 Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id r4LMDLt1016593; Tue, 21 May 2013 18:13:21 -0400 (EDT) To: Jeffrey Hutzelman References: <44302EA3-1CB6-4F9A-A6B4-25F5FCDBCC0A@tycho.ncsc.mil> <7E40423E-7040-4AD5-9135-97032369CAC0@tycho.ncsc.mil> <1223_1369160296_r4LIIFoA001408_tsl8v38urhh.fsf@mit.edu> <1369168798.2711.787.camel@minbar.fac.cs.cmu.edu> From: Tom Yu Date: Tue, 21 May 2013 18:13:21 -0400 In-Reply-To: <1369168798.2711.787.camel@minbar.fac.cs.cmu.edu> (Jeffrey Hutzelman's message of "Tue, 21 May 2013 16:39:58 -0400") Message-ID: Lines: 11 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOIsWRmVeSWpSXmKPExsUixCmqrNvycXagwcXVxhZf2x6wWVx/f47d 4ujmVSwOzB77W4+xeixZ8pPJY+XU0+wBzFFcNimpOZllqUX6dglcGbefXWAtOMRScav5P3sD 40XmLkZODgkBE4l9bcvYIWwxiQv31rN1MXJxCAnsY5T4PWUOE4SzkVHi6tM9UJlzTBI9XT+g Ml2MEvverGQB6RcRUJW4N2cWmM0sYCFxf+9URhBbWMBD4uHKZ1DdB1klZq56DdTNwcEmIC1x dHEZSA0LUO/zNbPYQWo4BRoZJRZd2MoOUsMLNOhpqyKIySPAKXFiSiVIOa+AoMTJmU+gVmlJ 3Pj3kmkCo+AsJKlZSFILGJlWMcqm5Fbp5iZm5hSnJusWJyfm5aUW6Rrq5WaW6KWmlG5iBIev JM8OxjcHlQ4xCnAwKvHwPqidHSjEmlhWXJl7iFGSg0lJlHfya6AQX1J+SmVGYnFGfFFpTmrx IUYJDmYlEV7Da0A53pTEyqrUonyYlDQHi5I47+WUm/5CAumJJanZqakFqUUwWRkODiUJ3r4P QI2CRanpqRVpmTklCGkmDk6Q4TxAw+VAaniLCxJzizPTIfKnGBWlxHlngCQEQBIZpXlwvbD0 8opRHOgVYd7VIFU8wNQE1/0KaDAT0ODtljNBBpckIqSkGhgFI272b0v6GDtj4uqkZ9/mrp2l xWolVOC8bL6kcF/GTO9Obp+5hfvnPveS3mUYcy/kasPy+08sZSN3Ts/506Zw2rB7x8I5fx7u v9tnEBO51P/RLbMytY/SU/44/Xup2eK83rpdZJ3cdK7cjvh51XypVhFPGExfFoZsD9q0j93g zX//uhe+Na5KLMUZiYZazEXFiQCLw2tdCgMAAA== Cc: kitten@ietf.org, Sam Hartman Subject: Re: [kitten] Comments on draft-ietf-kitten-aes-cts-hmac-sha2-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 22:13:33 -0000 Jeffrey Hutzelman writes: > On the other hand, I am very nervous about omitting the random secret > confounder used by existing enctypes. So far, I have seen neither an > indication of why this is necessary or why introducing a public IV makes > a secret confounder unnecessary. See the references I posted. If a random confounder provides additional security properties that a public IV does not, it would be useful to know what they are. It may be there's a nontrivial benefit to having a random secret confounder, but I haven't found one yet. From kwburgi@tycho.ncsc.mil Wed May 22 08:36:04 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B68521F911B for ; Wed, 22 May 2013 08:36:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.513 X-Spam-Level: X-Spam-Status: No, score=-10.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZDIgQws+a1f2 for ; Wed, 22 May 2013 08:35:58 -0700 (PDT) Received: from nsa.gov (emvm-gh1-uea09.nsa.gov [63.239.67.10]) by ietfa.amsl.com (Postfix) with ESMTP id 2F43C21F84FD for ; Wed, 22 May 2013 08:35:55 -0700 (PDT) X-TM-IMSS-Message-ID: <2c50b548000a0363@nsa.gov> Received: from tarius.tycho.ncsc.mil ([144.51.31.2]) by nsa.gov ([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1) id 2c50b548000a0363 ; Wed, 22 May 2013 11:38:49 -0400 Received: from rd6um-58422h.infosec.tycho.ncsc.mil (rd6um-58422h [192.168.26.151]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id r4MFZmRF029108; Wed, 22 May 2013 11:35:48 -0400 Message-Id: <9358351E-D3B6-49E3-B6B0-DDE71D95361C@tycho.ncsc.mil> From: Kelley Burgin To: Nico Williams In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 22 May 2013 11:39:38 -0400 References: <44302EA3-1CB6-4F9A-A6B4-25F5FCDBCC0A@tycho.ncsc.mil> <22606_1369111554_r4L4jrrH023245_CAK3OfOiRsqC1RxbU96OGzOUj0=UEcQbXNKPrhBAgYyybQDHD_Q@mail.gmail.com> <1369154928.2711.772.camel@minbar.fac.cs.cmu.edu> <5F29C375-8261-41B2-B188-1938C6201ABD@tycho.ncsc.mil> X-Mailer: Apple Mail (2.936) Cc: kitten@ietf.org, Sam Hartman , "Kevin M. Igoe" , Jeffrey Hutzelman Subject: Re: [kitten] Comments on draft-ietf-kitten-aes-cts-hmac-sha2-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2013 15:36:04 -0000 Nico, I had forgotten about the first block of cipher being the encryption of the IV - you're right that your scheme achieves all 3 security goals below. I haven't thought more about Tom's yet, but agree that we need to address the short-plaintext issue in the document and I'm happy to include whichever scheme we agree on. The non-security related reasons (in response to you and Jeff) for the decisions made in my draft, which deviate from Kerberos tradition are: The draft is intended to support the Suite B profile for Kerberos draft. Suite B is more than a set of algorithm choices - it provides NIST compliant security guidance and further systems requirements to achieve as secure a complete system as possible. There is no required "Suite B mode of encryption", but there is a rule that we follow: Use GCM when it makes sense, otherwise CBC (as specified in NIST SP800-38A, which specifies the use of padding and an explicit nonce). The krb-wg discussed using GCM years ago to conclude that it didn't make sense (counter rollover vulnerability issues), so we moved to CBC +padding+explicit IV. We eventually gave in to CTS mode around the same time the Addendum to SP800-38A came out standardizing CTS mode. Moving to implicit IV would deviate from NIST standards (SP800-38A Section 6.2 specifies the IV be xored with the first block of plaintext and encrypted to output the first block of ciphertext). It would also break the Suite B mode rule. The other protocols (that we've written Suite B profiles for) where GCM doesn't make sense use CBC mode with explicit IV: IKEv2 (in IPSec RFC) and S/MIME. There's also the performance issue that you pointed out that implicit IVs require an extra encryption and decryption operation per message, but send the same number of bytes on the wire as explicit IV, but this is less important to me than the Suite B/NIST philosophical issues above. Kelley On May 21, 2013, at 2:51 PM, Nico Williams wrote: > On Tue, May 21, 2013 at 12:05 PM, Kelley Burgin > wrote: >> In general, we want to >> 1. encrypt-then-mac, > > Agreed. > >> 2. include the IV directly in the MAC computation (so the MAC value >> H is >> different for the same output of the encryption operation C) and > > Note that this is true with confounding anyways: every ciphertext of > the same plaintext (as provided by the application) is randomized > because the plaintext prepended with a nonce. > > If there's something wrong with confounded encrypt-then-MAC (and > verify-then-decrypt) we should know, since we rely on confounding in > Kerberos today. > >> 3. on the receiving end check the MAC before decryption (to save >> decrypting >> a long message only to find out later that the MAC doesn't verify). > > And to avoid padding attacks. (It helps to have no padding, of > course.) > >> >> I'm probably fine with a scheme that doesn't do the last two in >> short-plaintext cases (like Tom's and Nico's). However, to achieve >> all >> three, the nonce needs to be sent as part of the ciphertext. > > No, my scheme gets you all three. Confounding does not preclude any > of (1), (2), nor (3). > > Nico > -- From nico@cryptonector.com Wed May 22 08:38:50 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF10321F93FC for ; Wed, 22 May 2013 08:38:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dXi15py-XRQn for ; Wed, 22 May 2013 08:38:45 -0700 (PDT) Received: from homiemail-a73.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id A6B7621F91BC for ; Wed, 22 May 2013 08:38:41 -0700 (PDT) Received: from homiemail-a73.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a73.g.dreamhost.com (Postfix) with ESMTP id 50ADE1F008A for ; Wed, 22 May 2013 08:38:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=eympN5exx+ylu//6Y9+m 00ApMlc=; b=m36OiDp8/zyxvcnIA4isD5avqqOWP8DGvKHyK3TFb57fjfG/oBt6 0J/PoIKurnw+kCEC2FXATJmejfg16I3C1RoQkSZmhjIg5zEF2J/nZKKhSkdL0SXN F2/YxRYyjoqw0XzWjTyAkf0iEVGSn3Fapz+j32wXez+GiTWYJ6NDZ30= Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a73.g.dreamhost.com (Postfix) with ESMTPSA id C9EC31F0086 for ; Wed, 22 May 2013 08:38:40 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id k13so1392985wgh.29 for ; Wed, 22 May 2013 08:38:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/13nZfpWFiapqqg2UBBe5ZFgnLpGG2IEhZZgAfvo+x0=; b=XE2NtA9cZOeRlpwJ+S3B3uCT4Ym7d985IlsBVfJZNKhnnZutqNRDkofyUjLNnX7ZrK /45r/p8M7CGwVBopp7arSGV5kfKtCeI+oYnccsy1A0+m8IDv5ghXolspfwVSZehWLb8k oINnFiSVcPftf0m2D0hTVPcBfuL4HDbuXd+z4dt7s9QfICC3N7Yp1TsuzY9RwiYtr4KI eKHbALejUEnX65biriV8bp3sJlWbB7eaqzXXNbdChcPGuBm37xA3gmVkGbkPzOo0aP+r vz0B1tfoqsOUxAAtGDYEh0I9Y6bVpjh/Huzp5Nbri0mdCN7h/MjFxhqb7ACefhXcx2Sj ehWw== MIME-Version: 1.0 X-Received: by 10.180.72.195 with SMTP id f3mr34395626wiv.32.1369237118776; Wed, 22 May 2013 08:38:38 -0700 (PDT) Received: by 10.216.111.132 with HTTP; Wed, 22 May 2013 08:38:38 -0700 (PDT) In-Reply-To: References: <44302EA3-1CB6-4F9A-A6B4-25F5FCDBCC0A@tycho.ncsc.mil> <7E40423E-7040-4AD5-9135-97032369CAC0@tycho.ncsc.mil> Date: Wed, 22 May 2013 10:38:38 -0500 Message-ID: From: Nico Williams To: Tom Yu Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org, Sam Hartman Subject: Re: [kitten] Comments on draft-ietf-kitten-aes-cts-hmac-sha2-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2013 15:38:50 -0000 On Tue, May 21, 2013 at 3:45 PM, Tom Yu wrote: > I think CBC with explicit random IV is better analyzed in the > literature. Encrypt-then-MAC is provably IND-CCA and INT-CTXT secure > given some reasonable assumptions about the MAC and the encryption > scheme. (Bellare and Namprempre, "Authenticated Encryption: Relations > among notions and analysis of the generic composition paradigm", > 2000.) > > The "simplified profile" in RFC 3961 (prepend confounder, then > independently MAC and CBC-encrypt with zero IV) is provably IND-CCA > and INT-CTXT secure. See Boldyreva and Kumar, "Provable-Security > Analysis of Authenticated Encryption in Kerberos", 2007. Among other > things, it aruges that CBC encryption with zero IV and random > confounder is at least as secure as CBC encryption with random IV. It should be obvious that confounding CBC (or CTS, which is a variation on CBC) is at least as secure as CBC (or CTS) with random IV. It follows from the fact that encryption with CBC and a confounder is the same as encrypting a random nonce (same size as an IV) to get an IV for use in encrypting the original plaintext -- encrypting the nonce can't degrade security. It is less obvious that confounding doesn't add security (and I think it doesn't). But then, CBC with a random IV meets our security needs and there's plenty of analysis to back this up. The main benefit to not confounding is performance: there's one fewer encryption/decryption operation per-RFC3962 encryption/decryption operation. For small messages this is a big deal. Some text for the intro section would be nice. And a solution to the short plaintext problem is critical (if nothing else because GSS consumers are free to use shorter plaintexts and we don't know if they do or don't; ditto AFS and other non-Internet protocols). I'm happy with either a counter or confounded short plaintext encryption solution, and I'd prefer the counter one on account of performance (again). Nico -- Nico -- From nico@cryptonector.com Wed May 22 08:51:53 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0407B21F9662 for ; Wed, 22 May 2013 08:51:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nVnDo2ZLczav for ; Wed, 22 May 2013 08:51:48 -0700 (PDT) Received: from homiemail-a16.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id CB21021F9654 for ; Wed, 22 May 2013 08:51:47 -0700 (PDT) Received: from homiemail-a16.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTP id 92AF450808F for ; Wed, 22 May 2013 08:51:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=2XDmCvVsr/OXoSUskZyq vkFYHGw=; b=mQrl7flbIM7huDHh+nVJ0ZlsGQGniJlh0J4BUVE2u8oAWq88uarz vrzd7tp7OZB8h+Py9qwZ7Z5SZyw0sUOQV76GdB4A3ph6EDvNs/Ias95hwuYuFU5g 0bbM9xYpt24o0Hq410CH1yk76QUQNLYBuLs9SRW2aMS+vqCuJJRs4w8= Received: from mail-wg0-f41.google.com (mail-wg0-f41.google.com [74.125.82.41]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTPSA id 362F950808E for ; Wed, 22 May 2013 08:51:47 -0700 (PDT) Received: by mail-wg0-f41.google.com with SMTP id c11so2725774wgh.4 for ; Wed, 22 May 2013 08:51:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9Ft7ooPDR1/p3Rm7Y8SyCgHRnTkI0QIU9cMxnf8wuHc=; b=UDYTW7flU9FnC5VeWiZoZA8sx5lT3GxjaB5OYh54VEVwvcVbur+qai/Ms0v6sTpgV+ DQ3M3zUwnD9g81KECpCmLCBMFwMobXuMdPq65//RL+SFOKEdAFjxbUyz93w0bFtla3hw jNNnrT070+9KsIY0rtX7DT+yEb6bRgd+Hr1dyIQkFySpnjFpOUIImHbwJgg/dt3BQDuX Vd0b0GHLdpJwi6WlIJ50J23J3m/dn5U2cZnkyxbkbHSQ1A6qWXr9OvddtBrHdK1eeQUM zcV4nk0fIruN5JEwcxPyyKBxtG93gh51TiafGIwvJkQ9NDgqO2/reDP9eZsK/1D8jJU8 87hQ== MIME-Version: 1.0 X-Received: by 10.180.189.41 with SMTP id gf9mr15855033wic.32.1369237905855; Wed, 22 May 2013 08:51:45 -0700 (PDT) Received: by 10.216.111.132 with HTTP; Wed, 22 May 2013 08:51:45 -0700 (PDT) In-Reply-To: <9358351E-D3B6-49E3-B6B0-DDE71D95361C@tycho.ncsc.mil> References: <44302EA3-1CB6-4F9A-A6B4-25F5FCDBCC0A@tycho.ncsc.mil> <22606_1369111554_r4L4jrrH023245_CAK3OfOiRsqC1RxbU96OGzOUj0=UEcQbXNKPrhBAgYyybQDHD_Q@mail.gmail.com> <1369154928.2711.772.camel@minbar.fac.cs.cmu.edu> <5F29C375-8261-41B2-B188-1938C6201ABD@tycho.ncsc.mil> <9358351E-D3B6-49E3-B6B0-DDE71D95361C@tycho.ncsc.mil> Date: Wed, 22 May 2013 10:51:45 -0500 Message-ID: From: Nico Williams To: Kelley Burgin Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org, Sam Hartman , "Kevin M. Igoe" , Jeffrey Hutzelman Subject: Re: [kitten] Comments on draft-ietf-kitten-aes-cts-hmac-sha2-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2013 15:51:53 -0000 On Wed, May 22, 2013 at 10:39 AM, Kelley Burgin wrote: Thanks. This is what I was looking for. I don't think confounding clashes philosophically with the NIST Suite B requirements. It clearly functions as CBC w/ random IV... it uses encryption to derive the IV from a nonce, but so what? The philosophical difference between CBC w/ random IV and CBC with confounding seems about as strong as that between CBC and CTS. That said: I'm happy to not confound, and I would found my personal choice to dump confounding on the performance gain to be had from not confounding. As for short-plaintext, I think I prefer Tom's counter mode solution (again, for performance reasons). Nico -- From tlyu@mit.edu Wed May 22 11:03:52 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DD1521F8E06 for ; Wed, 22 May 2013 11:03:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.299 X-Spam-Level: X-Spam-Status: No, score=-103.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eTsVyoD6Y0Ny for ; Wed, 22 May 2013 11:03:46 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (DMZ-MAILSEC-SCANNER-4.MIT.EDU [18.9.25.15]) by ietfa.amsl.com (Postfix) with ESMTP id B79B811E8106 for ; Wed, 22 May 2013 11:03:45 -0700 (PDT) X-AuditID: 1209190f-b7f256d000005616-b9-519d0880dc0a Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 38.06.22038.0880D915; Wed, 22 May 2013 14:03:44 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id r4MI3gBd002030; Wed, 22 May 2013 14:03:42 -0400 Received: from cathode-dark-space.mit.edu (CATHODE-DARK-SPACE.MIT.EDU [18.18.1.96]) (authenticated bits=56) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id r4MI3d5s005885 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 22 May 2013 14:03:41 -0400 Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id r4MI3dEl019504; Wed, 22 May 2013 14:03:39 -0400 (EDT) To: Nico Williams References: <44302EA3-1CB6-4F9A-A6B4-25F5FCDBCC0A@tycho.ncsc.mil> <7E40423E-7040-4AD5-9135-97032369CAC0@tycho.ncsc.mil> From: Tom Yu Date: Wed, 22 May 2013 14:03:39 -0400 In-Reply-To: (Nico Williams's message of "Wed, 22 May 2013 10:38:38 -0500") Message-ID: Lines: 40 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupmleLIzCtJLcpLzFFi42IRYrdT0W3gmBtosPabksXXtgdsFkc3r2Kx mNeQYXH61nNmi1PXjrA5sHq8PHWO0WPJkp9MHm8brrJ7rJx6mt1ja/M/xgDWKC6blNSczLLU In27BK6M51O+sBVMFKi4dmUrewNjA28XIweHhICJxM+bOV2MnECmmMSFe+vZuhi5OIQE9jFK 3Fn+EMrZyChx4NVfVgjnHJPE/ddroDJdjBItV/czg/SLCGhKXJ+3FCzBLDCFUeLu0m0sIAlh AQ+JhyufQXWsZpOYtHEaE8hyNgFpiaOLy0BqWARUJY6u6QVbwSkwgVHi4fy3zCA1vAIWElsm V4DU8AhwSjz8uIwRxOYVEJQ4OfMJ2HxmAS2JG/9eMk1gFJyFJDULSWoBI9MqRtmU3Crd3MTM nOLUZN3i5MS8vNQiXRO93MwSvdSU0k2MoDDnlOTfwfjtoNIhRgEORiUe3gM35gQKsSaWFVfm HmKU5GBSEuU1/AcU4kvKT6nMSCzOiC8qzUktPsQowcGsJMKb9Rcox5uSWFmVWpQPk5LmYFES 572actNfSCA9sSQ1OzW1ILUIJivDwaEkwfuFbW6gkGBRanpqRVpmTglCmomDE2Q4D9BwcXag Gt7igsTc4sx0iPwpRkUpcV5dkIQASCKjNA+uF5aGXjGKA70izPsIZAUPMIXBdb8CGswENHjp KZCri0sSEVJSDYy5y5OUw72bl4mvFrnxnuH89bPf7He28D/6c2SunsLvFfdU5ONW52oXeehe rb8jwN7PfeRV5OUkfr0k2Sp9814Vzlg11hL+loYL6u/neKslG3eIn9a4L/gqqfDTnN7yc8Fz Z69RcLaunieYZ3pcd9kGfhPHb8Ui6gJNUZ+6mecHRK7bIy28X4mlOCPRUIu5qDgRAMp6r1we AwAA Cc: kitten@ietf.org, Sam Hartman Subject: Re: [kitten] Comments on draft-ietf-kitten-aes-cts-hmac-sha2-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2013 18:03:52 -0000 Nico Williams writes: > It should be obvious that confounding CBC (or CTS, which is a > variation on CBC) is at least as secure as CBC (or CTS) with random > IV. It follows from the fact that encryption with CBC and a > confounder is the same as encrypting a random nonce (same size as an > IV) to get an IV for use in encrypting the original plaintext -- > encrypting the nonce can't degrade security. > > It is less obvious that confounding doesn't add security (and I think > it doesn't). But then, CBC with a random IV meets our security needs > and there's plenty of analysis to back this up. I think I generally agree with the above. I'm not aware of any significant specific benefit that a secret confounder provides beyond what a public random IV does. Anyone know of relevant results in the research literature? > The main benefit to not confounding is performance: there's one fewer > encryption/decryption operation per-RFC3962 encryption/decryption > operation. For small messages this is a big deal. CTS encryption and decryption aren't symmetric in cost. CTS encryption of a message can use an underlying CBC encryption primitive and only need to invoke it once. CTS decryption, on the other hand, will need to invoke the underlying CBC decryption primitive twice in the general case. (It's possible to reduce it to only one invocation, but not without making some questionable assumptions about the internals of the CBC decryption primitive.) > Some text for the intro section would be nice. And a solution to the > short plaintext problem is critical (if nothing else because GSS > consumers are free to use shorter plaintexts and we don't know if they > do or don't; ditto AFS and other non-Internet protocols). I'm happy > with either a counter or confounded short plaintext encryption > solution, and I'd prefer the counter one on account of performance > (again). I agree that some additional text in the introduction explaining the design choices would be useful. From kwburgi@tycho.ncsc.mil Wed May 22 12:05:57 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C331E11E8106 for ; Wed, 22 May 2013 12:05:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.224 X-Spam-Level: X-Spam-Status: No, score=-10.224 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IXarxGawHUS5 for ; Wed, 22 May 2013 12:05:52 -0700 (PDT) Received: from nsa.gov (emvm-gh1-uea08.nsa.gov [63.239.67.9]) by ietfa.amsl.com (Postfix) with ESMTP id AA8DA11E80FB for ; Wed, 22 May 2013 12:05:51 -0700 (PDT) X-TM-IMSS-Message-ID: <50d93205000b1def@nsa.gov> Received: from tarius.tycho.ncsc.mil ([144.51.31.2]) by nsa.gov ([63.239.67.9]) with ESMTP (TREND IMSS SMTP Service 7.1) id 50d93205000b1def ; Wed, 22 May 2013 15:05:04 -0400 Received: from rd6um-58422h.infosec.tycho.ncsc.mil (rd6um-58422h [192.168.26.151]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id r4MJ5fEs004197; Wed, 22 May 2013 15:05:41 -0400 Message-Id: <8138C036-FAA0-43E1-A952-902FE998A640@tycho.ncsc.mil> From: Kelley Burgin To: Tom Yu In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 22 May 2013 15:09:31 -0400 References: <44302EA3-1CB6-4F9A-A6B4-25F5FCDBCC0A@tycho.ncsc.mil> <7E40423E-7040-4AD5-9135-97032369CAC0@tycho.ncsc.mil> X-Mailer: Apple Mail (2.936) Cc: kitten@ietf.org, Sam Hartman , Jeffrey Hutzelman Subject: Re: [kitten] Comments on draft-ietf-kitten-aes-cts-hmac-sha2-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2013 19:05:57 -0000 I'm happy to give an explanation of design choices in the document. (especially those that differ from Kerberos tradition) Looking over Tom's short-plaintext scheme again, I see the mistake I made in reading the variables. It looks good to me, with one question: is len(C) ever anything but blocksize? plen = len(plaintext) if plen < blocksize: C = Enc-CBC(Ke, plaintext | nullpad, IV) N1 = C[1..blocksize] <-- question here C1 = N[1..plen] H = HMAC(Ki, N1 | C1) ciphertext = N1 | C1 | H[1..h] What is the feeling about including some text on the structure of salts (in particular the inclusion of random valid UTF-8 sequences) in the document? Does this make sense here? Is it worth a separate document? Kelley On May 22, 2013, at 2:03 PM, Tom Yu wrote: > Nico Williams writes: > >> It should be obvious that confounding CBC (or CTS, which is a >> variation on CBC) is at least as secure as CBC (or CTS) with random >> IV. It follows from the fact that encryption with CBC and a >> confounder is the same as encrypting a random nonce (same size as an >> IV) to get an IV for use in encrypting the original plaintext -- >> encrypting the nonce can't degrade security. >> >> It is less obvious that confounding doesn't add security (and I think >> it doesn't). But then, CBC with a random IV meets our security needs >> and there's plenty of analysis to back this up. > > I think I generally agree with the above. I'm not aware of any > significant specific benefit that a secret confounder provides beyond > what a public random IV does. Anyone know of relevant results in the > research literature? > >> The main benefit to not confounding is performance: there's one fewer >> encryption/decryption operation per-RFC3962 encryption/decryption >> operation. For small messages this is a big deal. > > CTS encryption and decryption aren't symmetric in cost. CTS > encryption of a message can use an underlying CBC encryption primitive > and only need to invoke it once. CTS decryption, on the other hand, > will need to invoke the underlying CBC decryption primitive twice in > the general case. (It's possible to reduce it to only one invocation, > but not without making some questionable assumptions about the > internals of the CBC decryption primitive.) > >> Some text for the intro section would be nice. And a solution to the >> short plaintext problem is critical (if nothing else because GSS >> consumers are free to use shorter plaintexts and we don't know if >> they >> do or don't; ditto AFS and other non-Internet protocols). I'm happy >> with either a counter or confounded short plaintext encryption >> solution, and I'd prefer the counter one on account of performance >> (again). > > I agree that some additional text in the introduction explaining the > design choices would be useful. From mrex@sap.com Wed May 22 19:57:47 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 966DA11E8134 for ; Wed, 22 May 2013 19:57:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rLwQwmfGqzlR for ; Wed, 22 May 2013 19:57:43 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 0904F11E812A for ; Wed, 22 May 2013 19:57:42 -0700 (PDT) Received: from mail06.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id r4N2vdnj020424 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 23 May 2013 04:57:39 +0200 (MEST) In-Reply-To: <5F29C375-8261-41B2-B188-1938C6201ABD@tycho.ncsc.mil> To: Kelley Burgin Date: Thu, 23 May 2013 04:57:39 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20130523025739.42F961A76F@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: kitten@ietf.org, Sam Hartman , Jeffrey Hutzelman Subject: [kitten] Origins of the CBC padding scheme (PEM rather than PKCS#5?) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 02:57:47 -0000 Slightly off-topic: Kelley Burgin wrote: > > (the intended applications there don't have a problem with PKCS#5 padding) I'm confused, where does the term "PKCS#5 padding" come from? While there is a specific DES-CBC (and DES-EDE3-CBC) padding for 64-bit block ciphers described in PKCS#5 (e.g. v2.0 rfc2898), - that padding is strictly limited to 64-bit - that padding is explicitly described as "being taken from rfc1423" (->Privacy Enhanced Mail (PEM)) http://tools.ietf.org/html/rfc2898#page-13 Curiously, rfc1423 is similarily limited to 64-bit block ciphers (DES): http://tools.ietf.org/html/rfc1423#page-3 A "generalization" of that padding scheme for block sizes up to 255 octets can be found in PKCS#7 v1.5 end of section 10.3 (rfc2315): http://tools.ietf.org/html/rfc2315#page-22 2. Some content-encryption algorithms assume the input length is a multiple of k octets, where k > 1, and let the application define a method for handling inputs whose lengths are not a multiple of k octets. For such algorithms, the method shall be to pad the input at the trailing end with k - (l mod k) octets all having value k - (l mod k), where l is the length of the input. In other words, the input is padded at the trailing end with one of the following strings: 01 -- if l mod k = k-1 02 02 -- if l mod k = k-2 . . . k k ... k k -- if l mod k = 0 The padding can be removed unambiguously since all input is padded and no padding string is a suffix of another. This padding method is well-defined if and only if k < 256; methods for larger k are an open issue for further study. -Martin From kwburgi@tycho.ncsc.mil Thu May 23 05:46:00 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B67021F9349 for ; Thu, 23 May 2013 05:46:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.499 X-Spam-Level: X-Spam-Status: No, score=-10.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nMcCQNnzjTM5 for ; Thu, 23 May 2013 05:45:55 -0700 (PDT) Received: from nsa.gov (emvm-gh1-uea08.nsa.gov [63.239.67.9]) by ietfa.amsl.com (Postfix) with ESMTP id A35A521F9371 for ; Thu, 23 May 2013 05:45:50 -0700 (PDT) X-TM-IMSS-Message-ID: <54a3ad21000bbb16@nsa.gov> Received: from tarius.tycho.ncsc.mil ([144.51.31.2]) by nsa.gov ([63.239.67.9]) with ESMTP (TREND IMSS SMTP Service 7.1) id 54a3ad21000bbb16 ; Thu, 23 May 2013 08:45:05 -0400 Received: from rd6um-58422h.infosec.tycho.ncsc.mil (rd6um-58422h [192.168.26.151]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id r4NCjhHC023323; Thu, 23 May 2013 08:45:43 -0400 Message-Id: From: Kelley Burgin To: mrex@sap.com In-Reply-To: <20130523025739.42F961A76F@ld9781.wdf.sap.corp> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 23 May 2013 08:49:35 -0400 References: <20130523025739.42F961A76F@ld9781.wdf.sap.corp> X-Mailer: Apple Mail (2.936) Cc: kitten@ietf.org, Sam Hartman , Jeffrey Hutzelman Subject: Re: [kitten] Origins of the CBC padding scheme (PEM rather than PKCS#5?) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 12:46:00 -0000 Sorry for the confusion. I was referring to Section B.2.5 of PKCS#5 v2.1 (AES-CBC-Pad) which points to RFC 5652 (CMS, derived from PKCS#7). Kelley On May 22, 2013, at 10:57 PM, Martin Rex wrote: > Slightly off-topic: > > Kelley Burgin wrote: >> >> (the intended applications there don't have a problem with PKCS#5 >> padding) > > I'm confused, where does the term "PKCS#5 padding" come from? > > While there is a specific DES-CBC (and DES-EDE3-CBC) padding for > 64-bit block ciphers described in PKCS#5 (e.g. v2.0 rfc2898), > > - that padding is strictly limited to 64-bit > > - that padding is explicitly described as > "being taken from rfc1423" (->Privacy Enhanced Mail (PEM)) > > http://tools.ietf.org/html/rfc2898#page-13 > > > Curiously, rfc1423 is similarily limited to 64-bit block ciphers > (DES): > > http://tools.ietf.org/html/rfc1423#page-3 > > > A "generalization" of that padding scheme for block sizes up to 255 > octets > can be found in PKCS#7 v1.5 end of section 10.3 (rfc2315): > > http://tools.ietf.org/html/rfc2315#page-22 > > > 2. Some content-encryption algorithms assume the > input length is a multiple of k octets, where k > 1, and > let the application define a method for handling inputs > whose lengths are not a multiple of k octets. For such > algorithms, the method shall be to pad the input at the > trailing end with k - (l mod k) octets all having value > k - > (l mod k), where l is the length of the input. In other > words, the input is padded at the trailing end with one of > the following strings: > > 01 -- if l mod k = k-1 > 02 02 -- if l mod k = k-2 > . > . > . > k k ... k k -- if l mod k = 0 > > The padding can be removed unambiguously since all input > is > padded and no padding string is a suffix of another. This > padding method is well-defined if and only if k < 256; > methods for larger k are an open issue for further study. > > > -Martin From kaduk@mit.edu Thu May 23 08:05:33 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4296711E80F9 for ; Thu, 23 May 2013 08:05:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6a8dMTLDkkKE for ; Thu, 23 May 2013 08:05:26 -0700 (PDT) Received: from dmz-mailsec-scanner-7.mit.edu (DMZ-MAILSEC-SCANNER-7.MIT.EDU [18.7.68.36]) by ietfa.amsl.com (Postfix) with ESMTP id E365D11E80E9 for ; Thu, 23 May 2013 08:05:25 -0700 (PDT) X-AuditID: 12074424-b7f8c6d0000028c4-9c-519e3034b23b Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 1E.86.10436.4303E915; Thu, 23 May 2013 11:05:24 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id r4NF5MUU012784; Thu, 23 May 2013 11:05:24 -0400 Received: from multics.mit.edu (SYSTEM-LOW-SIPB.MIT.EDU [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id r4NF5I5F010676 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 23 May 2013 11:05:20 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id r4NF5IOE005771; Thu, 23 May 2013 11:05:18 -0400 (EDT) Date: Thu, 23 May 2013 11:05:18 -0400 (EDT) From: Benjamin Kaduk To: Kelley Burgin In-Reply-To: <8138C036-FAA0-43E1-A952-902FE998A640@tycho.ncsc.mil> Message-ID: References: <44302EA3-1CB6-4F9A-A6B4-25F5FCDBCC0A@tycho.ncsc.mil> <7E40423E-7040-4AD5-9135-97032369CAC0@tycho.ncsc.mil> <8138C036-FAA0-43E1-A952-902FE998A640@tycho.ncsc.mil> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHIsWRmVeSWpSXmKPExsUixCmqrGtiMC/Q4PU7S4ujm1exWMxryHBg 8liy5CeTx9bmf4wBTFFcNimpOZllqUX6dglcGadatzEXbGar2PbvIVsDYw9rFyMnh4SAicSi zb9YIGwxiQv31rN1MXJxCAnsY5Q4PvMcI4SzkVHiS8MdVgjnEJPExqnrmCCcBkaJV6fnsIH0 swhoSxx8OocRxGYTUJGY+WYjWFxEQEvi6sM5zCA2s4CwxPpzM8BsYQEPiYcrn4HVcAo4Sexe 8RgszivgIHHi1DuoO36xSaz7cJcdJCEqoCOxev8UFogiQYmTM5+wQAy1lDj35zrbBEbBWUhS s5CkFjAyrWKUTcmt0s1NzMwpTk3WLU5OzMtLLdI118vNLNFLTSndxAgKVnYXlR2MzYeUDjEK cDAq8fDO0JkXKMSaWFZcmXuIUZKDSUmU11cPKMSXlJ9SmZFYnBFfVJqTWnyIUYKDWUmE11oZ KMebklhZlVqUD5OS5mBREue9nnLTX0ggPbEkNTs1tSC1CCYrw8GhJMHLrw/UKFiUmp5akZaZ U4KQZuLgBBnOAzScBaSGt7ggMbc4Mx0if4pRUUqc9yPIRQIgiYzSPLheWDJ5xSgO9IowryhI Ow8wEcF1vwIazAQ0eOmpOSCDSxIRUlINjAsXlEpdXuLi7ZyaY9utVsyrdHb3deWGiLP7GWL4 FeQT2ZZu5lbYc5f/yc/eplXL/b3XvvRaOL/fROj/nHleOUqeEVPrz8xKYTFf1iBv6nf8Cc/N FMbJrjeiPRebRTD5KWx3TJrp7nHrTObLg3cOHL+24Px8w8vhM9T5Z0br/WxenMspqrQuVoml OCPRUIu5qDgRALEoxp0BAwAA Cc: kitten@ietf.org Subject: Re: [kitten] Comments on draft-ietf-kitten-aes-cts-hmac-sha2-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 15:05:33 -0000 On Wed, 22 May 2013, Kelley Burgin wrote: > I'm happy to give an explanation of design choices in the document. > (especially those that differ from Kerberos tradition) That would be good, thanks. > What is the feeling about including some text on the structure of salts (in > particular the inclusion of random valid UTF-8 sequences) in the document? > Does this make sense here? Is it worth a separate document? I think it would be reasonable to include a "suite B considerations" (or similar) section at the end, possibly even in the security considerations, noting that this enctype is proposed to support a suite B profile, which will want random salts, and that salts must be valid UTF-8. Hmm, I wonder whether the concept of a "random valid UTF-8 sequence" is well-defined... -Ben From nico@cryptonector.com Thu May 23 08:27:41 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6B0511E8143 for ; Thu, 23 May 2013 08:27:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.752 X-Spam-Level: X-Spam-Status: No, score=-1.752 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mE12Og3hvwsC for ; Thu, 23 May 2013 08:27:36 -0700 (PDT) Received: from homiemail-a77.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id BABB711E815C for ; Thu, 23 May 2013 08:27:34 -0700 (PDT) Received: from homiemail-a77.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTP id 09AA39405C for ; Thu, 23 May 2013 08:27:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=gqbYo9dZHzP9QhZ9k6Mc YP4GyWQ=; b=p2gARd8M/QScJoU6p8w0fMt7TXE911aFTpkgxv6bMNb6JOHbi43j TfnYsFmqB+BpTCw8MPSPxtjnijmSVU1PxTB/KJ69vQwHGEySGRU6GcvnqBVLMvl7 qE75AN/tqRZzlibwkH6FvpOkDW1f7O536ZZdYTyDatNaV+HM6DEdSIs= Received: from mail-wi0-f171.google.com (mail-wi0-f171.google.com [209.85.212.171]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTPSA id AB24C9406D for ; Thu, 23 May 2013 08:27:27 -0700 (PDT) Received: by mail-wi0-f171.google.com with SMTP id hq7so4647339wib.4 for ; Thu, 23 May 2013 08:27:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=u65eeXc/+tom8ebktriCMNGlE2cb/Py4y7Mb+oG2QOM=; b=iPVIwkD9a485Ne9aNOWJvBKFM28jOcb3XStaa0aCe9mbYXI6LJLLWFbFiFB9o9kOpj VSqHwszZQNVM4Fz96UbQL0UqO0QjjsawncngIZvmD8KJUtsQQuVg03A5PDf+D2f4W7m+ 4DbPxJdsGj3CV39VfEQ7uT7WEMNwPDbp56Dp61K1Vlu7qhD+nHNVsNql2wxGk1WOeR5j B32FCh3tL5+R+r+P8WOOWl4/FRCCvmOhFCV1GFoK9Rc17hFt4ZOiIf5oPdwlXssflbaR jgr81Sfna7cyg6u7LYooyMufW6Ns3mWb+FuT5rwrwhCz/fTDn2yWaGZMrSkjNJXAxbY2 SSlw== MIME-Version: 1.0 X-Received: by 10.180.74.172 with SMTP id u12mr5889082wiv.0.1369322846312; Thu, 23 May 2013 08:27:26 -0700 (PDT) Received: by 10.216.111.132 with HTTP; Thu, 23 May 2013 08:27:26 -0700 (PDT) In-Reply-To: References: <44302EA3-1CB6-4F9A-A6B4-25F5FCDBCC0A@tycho.ncsc.mil> <7E40423E-7040-4AD5-9135-97032369CAC0@tycho.ncsc.mil> <8138C036-FAA0-43E1-A952-902FE998A640@tycho.ncsc.mil> Date: Thu, 23 May 2013 10:27:26 -0500 Message-ID: From: Nico Williams To: Benjamin Kaduk Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org Subject: Re: [kitten] Comments on draft-ietf-kitten-aes-cts-hmac-sha2-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 15:27:41 -0000 On Thu, May 23, 2013 at 10:05 AM, Benjamin Kaduk wrote: > I think it would be reasonable to include a "suite B considerations" (or > similar) section at the end, possibly even in the security considerations, > noting that this enctype is proposed to support a suite B profile, which > will want random salts, and that salts must be valid UTF-8. Hmm, I wonder > whether the concept of a "random valid UTF-8 sequence" is well-defined... Zalgo comes to mind... From hartmans@mit.edu Thu May 23 12:59:27 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A0C421F94F9 for ; Thu, 23 May 2013 12:59:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NqzC7g41cIsE for ; Thu, 23 May 2013 12:59:13 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 270F421F988E for ; Thu, 23 May 2013 12:19:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id ECEC920618; Thu, 23 May 2013 15:16:23 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3KHytTGHfo9X; Thu, 23 May 2013 15:16:23 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (unknown [10.1.10.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Thu, 23 May 2013 15:16:23 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 6D823440B; Thu, 23 May 2013 15:19:24 -0400 (EDT) From: Sam Hartman To: Kelley Burgin References: <44302EA3-1CB6-4F9A-A6B4-25F5FCDBCC0A@tycho.ncsc.mil> <7E40423E-7040-4AD5-9135-97032369CAC0@tycho.ncsc.mil> <8138C036-FAA0-43E1-A952-902FE998A640@tycho.ncsc.mil> Date: Thu, 23 May 2013 15:19:24 -0400 In-Reply-To: <8138C036-FAA0-43E1-A952-902FE998A640@tycho.ncsc.mil> (Kelley Burgin's message of "Wed, 22 May 2013 15:09:31 -0400") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: kitten@ietf.org, Sam Hartman , Jeffrey Hutzelman Subject: [kitten] Salts in aes sha2 draft X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 19:59:27 -0000 Speaking as an individual. Comments on the salt issue. I think that thinking about salting and password hashing has advanced significantly since 4120. I think that including a section in a document defining a new enctype updating our thinking on salting and password hashing would be valuable. If I were wwriting that section I'd include: 1) value of random salts 2) Issues you run into with Kerberos 2.1) Specifically including the issue of finding salt to construct a keytab 2.2) And cross-realm keys 3) Discuss mitigations for 2 3.1) How well does performing an as-req and looking at the etype-info2 work in both cases. Probably fine for servers and perhaps not so fine for cross-realm 3.2) Well, there is Nico's set/change password draft, that unfortunately no one is interested in implementing. From nico@cryptonector.com Thu May 23 13:20:03 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 673B221F85F4 for ; Thu, 23 May 2013 13:20:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.813 X-Spam-Level: X-Spam-Status: No, score=-1.813 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 940cCLYaXoue for ; Thu, 23 May 2013 13:19:48 -0700 (PDT) Received: from homiemail-a85.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id 4392F21F86AE for ; Thu, 23 May 2013 12:39:40 -0700 (PDT) Received: from homiemail-a85.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a85.g.dreamhost.com (Postfix) with ESMTP id BFF22BC034 for ; Thu, 23 May 2013 12:39:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=o+J65LNf/BiKOnCjJTnD oQeiACs=; b=FsbBSlbo72Y1aN12YiJgWQUgbWhBtvZZ9fpXWGW8ei7HREuhA4HI QcDHPrGqRF8jLPBRRg2j9Fe65T/E1hRAvAsAyA3xpK69bj7pzawdlrtn81M0nsCz UBdMG3OGW4b49LHmSwGTWVhbUBq0rJDDIXbun21R5L0RKAo5EphDIjc= Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a85.g.dreamhost.com (Postfix) with ESMTPSA id 40266BC004 for ; Thu, 23 May 2013 12:39:39 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id hj6so1070902wib.5 for ; Thu, 23 May 2013 12:39:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=g2Q6gU8BKRKiMyFiqa6yBzeRRP7s28jSGCbpZytQ/RE=; b=XKtQEqdtiu9BqseMTkBwfSuBGnj7Mg8c9Pojvf0UIDqnzR5IPGJymTDQo/DDkauAWd Tgki4VGToXi3dIaUOPK18Y3CV9SPf2TqYfS6JOD9YbmzLaCr8SxBJnHcO/cIwkJJBnHe dgJGe7ldDpkizhzKp6uRfYecejnUcPV4EjHM9bitx8cY5b2xrhpTqk4jlQVCJ9o+WkPH NpkOi5rAGirfMJWkY7l5Lh5/qcXsW/tyW24COLRM/++vMHZOWqRFc3NTIVOjombLXeii wOqqBpVcS1lbEsv/YkBbuEHdxONSO3Odfm3uLvXhBy7ajp2RRMyHsobpeear6hiGlgKv cW9Q== MIME-Version: 1.0 X-Received: by 10.180.185.207 with SMTP id fe15mr27383053wic.33.1369337977528; Thu, 23 May 2013 12:39:37 -0700 (PDT) Received: by 10.216.111.132 with HTTP; Thu, 23 May 2013 12:39:37 -0700 (PDT) In-Reply-To: References: <44302EA3-1CB6-4F9A-A6B4-25F5FCDBCC0A@tycho.ncsc.mil> <7E40423E-7040-4AD5-9135-97032369CAC0@tycho.ncsc.mil> <8138C036-FAA0-43E1-A952-902FE998A640@tycho.ncsc.mil> Date: Thu, 23 May 2013 14:39:37 -0500 Message-ID: From: Nico Williams To: Sam Hartman Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org, Jeffrey Hutzelman Subject: Re: [kitten] Salts in aes sha2 draft X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 20:20:03 -0000 On Thu, May 23, 2013 at 2:19 PM, Sam Hartman wrote: > 1) value of random salts If random salts are valuable (I think they are, though *any* salt that's different for each principal gets us most of the value of salts) then salts must be changed when passwords are changed. Otherwise the fact that a salt was initially selected randomly loses the benefit of having been selected randomly: an attacker can see what the salt is, after all. > 2) Issues you run into with Kerberos > > 2.1) Specifically including the issue of finding salt to construct a > keytab > > 2.2) And cross-realm keys They are both exactly the same issue. In both cases the resulting keys are added to a sort of key database. > 3) Discuss mitigations for 2 The only mitigations are: a) send an AS-REQ to learn the salt (and other s2kparams) with, or b) have the salt (and other s2kparams) at hand for off-line key generation. > 3.1) How well does performing an as-req and looking at the etype-info2 > work in both cases. Probably fine for servers and perhaps not so fine > for cross-realm It should work for both cases. A cross-realm relationship might be uni-directional, and there might be a firewall in place preventing AS-REQs in one direction, therefore the key should be added first to the realm whose KDCs are reachable by the other realm's admins. > 3.2) Well, there is Nico's set/change password draft, that unfortunately > no one is interested in implementing. Right. Forget it. Well, now that more implementations have/use ASN.1 compilers it might be worth reviving, but then, I think I'd just as well do a JSON-based change/set password protocol. Nico -- From hartmans@mit.edu Thu May 23 13:55:38 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B176821F92A5 for ; Thu, 23 May 2013 13:55:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5o9sDSwQKF0E for ; Thu, 23 May 2013 13:55:23 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id D657621F9765 for ; Thu, 23 May 2013 13:12:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 736BB2061A; Thu, 23 May 2013 16:09:47 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EeNOEcKy5a7s; Thu, 23 May 2013 16:09:46 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Thu, 23 May 2013 16:09:46 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id F119D440B; Thu, 23 May 2013 16:12:47 -0400 (EDT) From: Sam Hartman To: Nico Williams References: <44302EA3-1CB6-4F9A-A6B4-25F5FCDBCC0A@tycho.ncsc.mil> <7E40423E-7040-4AD5-9135-97032369CAC0@tycho.ncsc.mil> <8138C036-FAA0-43E1-A952-902FE998A640@tycho.ncsc.mil> Date: Thu, 23 May 2013 16:12:47 -0400 In-Reply-To: (Nico Williams's message of "Thu, 23 May 2013 14:39:37 -0500") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: kitten@ietf.org, Sam Hartman , Jeffrey Hutzelman Subject: Re: [kitten] Salts in aes sha2 draft X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 20:55:38 -0000 >>>>> "Nico" == Nico Williams writes: Nico> They are both exactly the same issue. In both cases the Nico> resulting keys are added to a sort of key database. I don't think they are exactly the same. I can think of many fewer reasons a realm would permit an AS-req with a cross-realm princ as a client than it would for a server. From nico@cryptonector.com Thu May 23 14:16:20 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8DD321F9607 for ; Thu, 23 May 2013 14:16:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qjiXGIXSkyfk for ; Thu, 23 May 2013 14:16:06 -0700 (PDT) Received: from homiemail-a77.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id 764C821F9759 for ; Thu, 23 May 2013 13:32:47 -0700 (PDT) Received: from homiemail-a77.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTP id 2E0089406B for ; Thu, 23 May 2013 13:32:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=pkrakzapRe98CQVgGKp+ EMVfZZg=; b=pX6p6C4s7Pc0f+FBdrGy30a8/Q+4ibVG6j3cRRUvt7r4+rttTSeE mJUD8NNV3u2hqoocp2oCwPtZRm8F0wsucUTM/j7nKRsIUxydEAsbX1fCtGVjP0Pn ryTWvs5pinlqhq50yNlzuSfrf1lkEdAqrKk8GFM51bpWATmjT+5S51A= Received: from mail-wg0-f54.google.com (mail-wg0-f54.google.com [74.125.82.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTPSA id 9F9B794065 for ; Thu, 23 May 2013 13:32:46 -0700 (PDT) Received: by mail-wg0-f54.google.com with SMTP id j13so915835wgh.21 for ; Thu, 23 May 2013 13:32:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KQWJgaQmZY4v9Epe88l3itUr5xFCX0FUEPVL6ycxpKo=; b=lC+PQftZt+B6uYpfIlCKW9p555N5zlUYMa2//j7BvXEAuDc1E8wPYwfhb0UukAWBhz AWkSdzuD42ZGDFZ2EUH50yZpnkRz8WTfYn9kVJc1f1mqbX1C2de3w0zsWwoQFhIh0T7y BWyCcPTWy2V0x7zBR8aojRYFZEweNMOf1F5KFTYinT2EU852tTEZtcJZ6aaGussnX7p/ EhheRlSTYu/aE5tT6xI3HW8RjdNNprQJjnmugH4mPy075/n8bcNhIIu32hpwLaWwZw4M 8/uq/KhMd8R7OhuvEHhy2hYbfQwJoli1+yaOUTouUoBmu0ncbgp7gLrIY3R2pPqOTBwz UsyQ== MIME-Version: 1.0 X-Received: by 10.180.185.207 with SMTP id fe15mr27727139wic.33.1369341162048; Thu, 23 May 2013 13:32:42 -0700 (PDT) Received: by 10.216.111.132 with HTTP; Thu, 23 May 2013 13:32:41 -0700 (PDT) In-Reply-To: References: <44302EA3-1CB6-4F9A-A6B4-25F5FCDBCC0A@tycho.ncsc.mil> <7E40423E-7040-4AD5-9135-97032369CAC0@tycho.ncsc.mil> <8138C036-FAA0-43E1-A952-902FE998A640@tycho.ncsc.mil> Date: Thu, 23 May 2013 15:32:41 -0500 Message-ID: From: Nico Williams To: Sam Hartman Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org, Jeffrey Hutzelman Subject: Re: [kitten] Salts in aes sha2 draft X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 21:16:21 -0000 On Thu, May 23, 2013 at 3:12 PM, Sam Hartman wrote: >>>>>> "Nico" == Nico Williams writes: > > Nico> They are both exactly the same issue. In both cases the > Nico> resulting keys are added to a sort of key database. > > I don't think they are exactly the same. I can think of many fewer > reasons a realm would permit an AS-req with a cross-realm princ as a > client than it would for a server. True, but though it might not permit it it should still serve the etype info2, so we get the salt for this purpose. From nico@cryptonector.com Thu May 23 14:31:38 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CF8721F985F for ; Thu, 23 May 2013 14:31:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L5kMUlfhUMj8 for ; Thu, 23 May 2013 14:31:23 -0700 (PDT) Received: from homiemail-a71.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id C205921F8976 for ; Thu, 23 May 2013 13:47:12 -0700 (PDT) Received: from homiemail-a71.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a71.g.dreamhost.com (Postfix) with ESMTP id 7BB57428076 for ; Thu, 23 May 2013 13:47:11 -0700 (PDT) Received: from mail-we0-f177.google.com (mail-we0-f177.google.com [74.125.82.177]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a71.g.dreamhost.com (Postfix) with ESMTPSA id 0A484428075 for ; Thu, 23 May 2013 13:47:10 -0700 (PDT) Received: by mail-we0-f177.google.com with SMTP id n57so2276124wev.36 for ; Thu, 23 May 2013 13:47:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=AMcj083kl8h4+FTyIzdw7I+ltZKy9vttK0K58x2B7NI=; b=Ha0zKCNMHfkXwqtzUQIAa5XhcFYxRvcZYbxvZuHMoonwxp0ALpfW07AZe57mo958mA vxNxNQqZjPdInQjpxCCGvTHVACuuCun+p8m+6vUpRHJik5f8CLOcLT6ck5Id+wCU1tyk Hn1lqGEQliYNqR5y3SY65p2FygMeR6enAu3txhrc3fsHoz+koC7+mGOzcIvF6fBmQH09 uLAJKJ1izwnfz3bn2Y8mxnylxj2KkemwSX68JOrjG1xBhjsTnGNtZEM/w4fvGlcilSkK AT+hNBk1giR76Fw03RgxFs45k5XthFceKxgMsfW//2Hy4r2ZpUw9xU3iyn4r2htkJIk/ tuEw== MIME-Version: 1.0 X-Received: by 10.180.185.207 with SMTP id fe15mr27772950wic.33.1369341690397; Thu, 23 May 2013 13:41:30 -0700 (PDT) Received: by 10.216.111.132 with HTTP; Thu, 23 May 2013 13:41:30 -0700 (PDT) In-Reply-To: References: <44302EA3-1CB6-4F9A-A6B4-25F5FCDBCC0A@tycho.ncsc.mil> <7E40423E-7040-4AD5-9135-97032369CAC0@tycho.ncsc.mil> <8138C036-FAA0-43E1-A952-902FE998A640@tycho.ncsc.mil> Date: Thu, 23 May 2013 15:41:30 -0500 Message-ID: From: Nico Williams To: Sam Hartman Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org, Jeffrey Hutzelman Subject: Re: [kitten] Salts in aes sha2 draft X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 21:31:38 -0000 Alternative mitigation for x-realm: don't randomize the salt. The x-realm password had better be very strong anyways. From kaduk@mit.edu Thu May 23 14:46:40 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4054921F9892 for ; Thu, 23 May 2013 14:46:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CiYAYq9Vp1lu for ; Thu, 23 May 2013 14:46:24 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (DMZ-MAILSEC-SCANNER-6.MIT.EDU [18.7.68.35]) by ietfa.amsl.com (Postfix) with ESMTP id 39B9021F93ED for ; Thu, 23 May 2013 13:59:14 -0700 (PDT) X-AuditID: 12074423-b7f826d000001438-f0-519e83211a52 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 6E.D7.05176.1238E915; Thu, 23 May 2013 16:59:13 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id r4NKxCVR001533; Thu, 23 May 2013 16:59:13 -0400 Received: from multics.mit.edu (SYSTEM-LOW-SIPB.MIT.EDU [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id r4NKxAFc014142 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 23 May 2013 16:59:12 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id r4NKxAoh020719; Thu, 23 May 2013 16:59:10 -0400 (EDT) Date: Thu, 23 May 2013 16:59:10 -0400 (EDT) From: Benjamin Kaduk To: Sam Hartman In-Reply-To: Message-ID: References: <7E40423E-7040-4AD5-9135-97032369CAC0@tycho.ncsc.mil> <8138C036-FAA0-43E1-A952-902FE998A640@tycho.ncsc.mil> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHIsWRmVeSWpSXmKPExsUixG6nrqvYPC/Q4FmPusXXtgdsFkc3r2Jx YPJYsuQnk8fKqafZA5iiuGxSUnMyy1KL9O0SuDJmvmhmK/jPXNG7spOlgXEqcxcjJ4eEgInE x5u3mCBsMYkL99azdTFycQgJ7GOUuPNlETuEs5FRYt7etYwgVUICh5gkXq6RgEg0MErMPnmd DSTBIqAtcfHdI7BRbAIqEjPfbASLiwioS7RP+ApmMwsIS6w/NwNstbCArkTf6VOsIDangJrE 1aZesAW8Ag4S+88+YIFYcIBdYsLWyWBDRQV0JFbvn8ICUSQocXLmExaIoZYS5/5cZ5vAKDgL SWoWktQCRqZVjLIpuVW6uYmZOcWpybrFyYl5ealFumZ6uZkleqkppZsYwcHqoryD8c9BpUOM AhyMSjy8H/TmBQqxJpYVV+YeYpTkYFIS5fVoBArxJeWnVGYkFmfEF5XmpBYfYpTgYFYS4S0M A8rxpiRWVqUW5cOkpDlYlMR5r6Xc9BcSSE8sSc1OTS1ILYLJynBwKEnwsjUBNQoWpaanVqRl 5pQgpJk4OEGG8wAN1wSp4S0uSMwtzkyHyJ9iVJQS530GcpEASCKjNA+uF5ZMXjGKA70izPsL pIoHmIjgul8BDWYCGrz01ByQwSWJCCmpBsbUtZPn80kc8fj+aFZoimxIv6mcl/Izt78CX9W/ 33w1b/6lWwauf07tjT99zm7f49Ks7yl7Vr/gP8C68+O/ebmPvacWn806fUnC+nCI08HYit/L v/45zLVt5qnUEO/v01vmrJ4xL+xQm4B1bnmxYcy02pspd2zUtLnivjktnphWkX5qbuSeu2yL lFiKMxINtZiLihMByrH3vAEDAAA= Cc: kitten@ietf.org Subject: Re: [kitten] Salts in aes sha2 draft X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 21:46:40 -0000 On Thu, 23 May 2013, Sam Hartman wrote: >>>>>> "Nico" == Nico Williams writes: > > I don't think they are exactly the same. I can think of many fewer > reasons a realm would permit an AS-req with a cross-realm princ as a > client than it would for a server. Didn't we talk about this (elsewhere) when considering how to unilaterally rekey a cross-realm trust? The AS protocol only had one realm field, was my recollection, so a cross-realm AS-req is impossible. -Ben From jhutz@cmu.edu Thu May 23 16:41:38 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE33D21F9634 for ; Thu, 23 May 2013 16:41:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MnwPU9fVGgzY for ; Thu, 23 May 2013 16:41:32 -0700 (PDT) Received: from smtp02.srv.cs.cmu.edu (SMTP02.SRV.CS.CMU.EDU [128.2.217.197]) by ietfa.amsl.com (Postfix) with ESMTP id 4366821F963C for ; Thu, 23 May 2013 16:41:30 -0700 (PDT) Received: from [192.168.1.122] (50-73-160-70-pennsylvania.hfc.comcastbusiness.net [50.73.160.70]) (authenticated bits=0) by smtp02.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id r4NNfNHH023428 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 23 May 2013 19:41:29 -0400 (EDT) Message-ID: <1369352483.2915.33.camel@destiny.pc.cs.cmu.edu> From: Jeffrey Hutzelman To: Benjamin Kaduk Date: Thu, 23 May 2013 19:41:23 -0400 In-Reply-To: <29927_1369345603_r4NLkgCg030787_alpine.GSO.1.10.1305231657190.9389@multics.mit.edu> References: <7E40423E-7040-4AD5-9135-97032369CAC0@tycho.ncsc.mil> <8138C036-FAA0-43E1-A952-902FE998A640@tycho.ncsc.mil> <29927_1369345603_r4NLkgCg030787_alpine.GSO.1.10.1305231657190.9389@multics.mit.edu> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.6.2-0ubuntu0.1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: mimedefang-cmuscs on 128.2.217.197 Cc: kitten@ietf.org, Sam Hartman , jhutz@cmu.edu Subject: Re: [kitten] Salts in aes sha2 draft X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 23:41:38 -0000 On Thu, 2013-05-23 at 16:59 -0400, Benjamin Kaduk wrote: > On Thu, 23 May 2013, Sam Hartman wrote: > > >>>>>> "Nico" == Nico Williams writes: > > > > I don't think they are exactly the same. I can think of many fewer > > reasons a realm would permit an AS-req with a cross-realm princ as a > > client than it would for a server. > > Didn't we talk about this (elsewhere) when considering how to unilaterally > rekey a cross-realm trust? The AS protocol only had one realm field, was > my recollection, so a cross-realm AS-req is impossible. Right; there's no way to express an AS-REQ in which the client and service are not in the same realm. From nico@cryptonector.com Thu May 23 17:16:55 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 393ED21F90AC for ; Thu, 23 May 2013 17:16:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.827 X-Spam-Level: X-Spam-Status: No, score=-1.827 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8I2WOBkNNxAX for ; Thu, 23 May 2013 17:16:50 -0700 (PDT) Received: from homiemail-a63.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id AE68821F925B for ; Thu, 23 May 2013 17:16:20 -0700 (PDT) Received: from homiemail-a63.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTP id 3DF1E2F4060 for ; Thu, 23 May 2013 17:16:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=+Nfw9q8RtvbCRFtVTY5K h4OE7zw=; b=A0wwrpapANR1mOAUJYcZT2hTk2ndCc7RBUJ63BeKqUSN54s8bYDW lmSq+rNgDKS4a52iThfqzvIQ77NLax3BKqL+t7LydxhmfpcOAFsqGRTfmA1CZfDG zO1NkJTH/QqxBadBFssGrdBwIqUbkji9A4BvVEMWIxf1x6iJYxi+z+I= Received: from mail-wi0-f171.google.com (mail-wi0-f171.google.com [209.85.212.171]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTPSA id DDC462F401D for ; Thu, 23 May 2013 17:16:19 -0700 (PDT) Received: by mail-wi0-f171.google.com with SMTP id hq7so4887227wib.16 for ; Thu, 23 May 2013 17:16:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=X2/lSq7TxRd6J6INLWT/AFZqTNOTppj3PWBiqyhVfCg=; b=iXtyRNCstCkliKFMZ60L0zRsD6um+0GP0Whjc1TYuvyIt6ONZk2jKqVlLnCLQ7IX6q +GWWywxuvY5f8i1FlteAIXwGJwN/iH2tWV8qnsxyKEUjSwQOfVOfWCc5WMNCKg0Y58D5 S2QYT1Jsg5co9R9yw/zUU229SaCTL991Kpx8Wu6UYWhvM6URHLl1wWicVgaHA1zCKVjz e0u4W3zciZIcl6MOVl2O0zYV6LptKQJg16+wrMkxeOiUkhm0YAg1wJNlxZ/41/DOk39E tfwAfew6khhAcuT99RWZgewcXWeBAUsXhvVZA1P9sNVAboJBC7sD3sXTEXnCbsXLkdh8 4zWQ== MIME-Version: 1.0 X-Received: by 10.180.183.139 with SMTP id em11mr48452156wic.16.1369354578344; Thu, 23 May 2013 17:16:18 -0700 (PDT) Received: by 10.216.111.132 with HTTP; Thu, 23 May 2013 17:16:18 -0700 (PDT) In-Reply-To: <1369352483.2915.33.camel@destiny.pc.cs.cmu.edu> References: <7E40423E-7040-4AD5-9135-97032369CAC0@tycho.ncsc.mil> <8138C036-FAA0-43E1-A952-902FE998A640@tycho.ncsc.mil> <29927_1369345603_r4NLkgCg030787_alpine.GSO.1.10.1305231657190.9389@multics.mit.edu> <1369352483.2915.33.camel@destiny.pc.cs.cmu.edu> Date: Thu, 23 May 2013 19:16:18 -0500 Message-ID: From: Nico Williams To: Jeffrey Hutzelman Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org, Sam Hartman Subject: Re: [kitten] Salts in aes sha2 draft X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 00:16:55 -0000 On Thu, May 23, 2013 at 6:41 PM, Jeffrey Hutzelman wrote: > On Thu, 2013-05-23 at 16:59 -0400, Benjamin Kaduk wrote: >> On Thu, 23 May 2013, Sam Hartman wrote: >> >> >>>>>> "Nico" == Nico Williams writes: >> > >> > I don't think they are exactly the same. I can think of many fewer >> > reasons a realm would permit an AS-req with a cross-realm princ as a >> > client than it would for a server. >> >> Didn't we talk about this (elsewhere) when considering how to unilaterally >> rekey a cross-realm trust? The AS protocol only had one realm field, was >> my recollection, so a cross-realm AS-req is impossible. > > Right; there's no way to express an AS-REQ in which the client and > service are not in the same realm. Right, but here the client principal *is* the x-realm principal in question, the service principal is irrelevant (could be the same as the client principal) and the KDC can be in either realm (whichever one the client principal was created in). Of course, if the x-realm principal is created first in the KDB of the *other* realm then there's no other principals that could be used as the service principal but itself. Either way, it should work. Ah, and completing the AS exchange has some value, particularly if the service is the same as the client principal: to validate the key. Keeping the salt secret (and if it's randomly generated) adds to the strength of... what should be a strong key to begin with, so I don't see any point in disallowing the AS exchange in this case. But it could be disabled after the key is exchanged. Anyways, we really need a DH x-realm key exchange protocol. And better: PKCROSS (and we don't need Ticket extensions, just encrypted (or authenticated anyways) PA-DATA. Nico -- From hartmans@mit.edu Thu May 23 19:23:27 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEE9321F9436 for ; Thu, 23 May 2013 19:23:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6dHboBEo8D97 for ; Thu, 23 May 2013 19:23:22 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 1972B21F8B16 for ; Thu, 23 May 2013 19:23:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 6E03C20618; Thu, 23 May 2013 22:20:17 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yQOZzKTwoKLg; Thu, 23 May 2013 22:20:16 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Thu, 23 May 2013 22:20:16 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 38E724206; Thu, 23 May 2013 22:23:18 -0400 (EDT) From: Sam Hartman To: Nico Williams References: <44302EA3-1CB6-4F9A-A6B4-25F5FCDBCC0A@tycho.ncsc.mil> <7E40423E-7040-4AD5-9135-97032369CAC0@tycho.ncsc.mil> <8138C036-FAA0-43E1-A952-902FE998A640@tycho.ncsc.mil> Date: Thu, 23 May 2013 22:23:18 -0400 In-Reply-To: (Nico Williams's message of "Thu, 23 May 2013 15:32:41 -0500") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: kitten@ietf.org, Sam Hartman , Jeffrey Hutzelman Subject: Re: [kitten] Salts in aes sha2 draft X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 02:23:28 -0000 >>>>> "Nico" == Nico Williams writes: Nico> On Thu, May 23, 2013 at 3:12 PM, Sam Hartman wrote: >>>>>>> "Nico" == Nico Williams writes: >> Nico> They are both exactly the same issue. In both cases the Nico> resulting keys are added to a sort of key database. >> >> I don't think they are exactly the same. I can think of many >> fewer reasons a realm would permit an AS-req with a cross-realm >> princ as a client than it would for a server. Nico> True, but though it might not permit it it should still serve Nico> the etype info2, so we get the salt for this purpose. Treating the issues differently so we could consider whether we want to recommend stuff like this was my primary motivation for calling out xrealm separately. From tlyu@mit.edu Thu May 23 20:05:44 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4766C21F949A for ; Thu, 23 May 2013 20:05:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.342 X-Spam-Level: X-Spam-Status: No, score=-103.342 tagged_above=-999 required=5 tests=[AWL=0.257, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K7cix8jzJT6k for ; Thu, 23 May 2013 20:05:37 -0700 (PDT) Received: from dmz-mailsec-scanner-1.mit.edu (DMZ-MAILSEC-SCANNER-1.MIT.EDU [18.9.25.12]) by ietfa.amsl.com (Postfix) with ESMTP id 3795821F87C5 for ; Thu, 23 May 2013 20:05:36 -0700 (PDT) X-AuditID: 1209190c-b7f566d000004c69-aa-519ed90056fc Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 6A.1F.19561.009DE915; Thu, 23 May 2013 23:05:36 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id r4O35YnS027083; Thu, 23 May 2013 23:05:34 -0400 Received: from cathode-dark-space.mit.edu (CATHODE-DARK-SPACE.MIT.EDU [18.18.1.96]) (authenticated bits=56) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id r4O35UUv011539 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 23 May 2013 23:05:32 -0400 Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id r4O35UHk024249; Thu, 23 May 2013 23:05:30 -0400 (EDT) To: Nico Williams References: <44302EA3-1CB6-4F9A-A6B4-25F5FCDBCC0A@tycho.ncsc.mil> <7E40423E-7040-4AD5-9135-97032369CAC0@tycho.ncsc.mil> From: Tom Yu Date: Thu, 23 May 2013 23:05:30 -0400 In-Reply-To: (Nico Williams's message of "Wed, 22 May 2013 10:38:38 -0500") Message-ID: Lines: 15 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplleLIzCtJLcpLzFFi42IRYrdT0WW4OS/QoGUhu8XXtgdsFkc3r2Kx mNeQYXH61nNmi1PXjrA5sHq8PHWO0WPJkp9MHm8brrJ7rJx6mt1ja/M/xgDWKC6blNSczLLU In27BK6M7jldLAWz2SqWH7vA3sDYwdrFyMkhIWAi8ebkdkYIW0ziwr31bF2MXBxCAvsYJWbu 7GGFcDYySky5+40JwjnHJHHiyn52CKeLUeLSpw6wfhEBTYnr85aC9TMLTGGUuLt0GwtIQljA Q+LhymdQg1ezSUzaOA1oFgcHm4C0xNHFZSA1LAKqEg/vbQRbwSkwgVHi4fy3zCAJXgELiTsT 17OD2DwCnBJNS3ZDxQUlTs58AraAWUBL4sa/l0wTGAVnIUnNQpJawMi0ilE2JbdKNzcxM6c4 NVm3ODkxLy+1SNdQLzezRC81pXQTIyjUOSV5djC+Oah0iFGAg1GJh3eGzrxAIdbEsuLK3EOM khxMSqK8F64BhfiS8lMqMxKLM+KLSnNSiw8xSnAwK4nwFoYB5XhTEiurUovyYVLSHCxK4ryX U276CwmkJ5akZqemFqQWwWRlODiUJHgvXAdqFCxKTU+tSMvMKUFIM3FwggznARr+FqSGt7gg Mbc4Mx0if4pRUUqc9xJIQgAkkVGaB9cLS0WvGMWBXhHmfQdSxQNMY3Ddr4AGMwENXnpqDsjg kkSElFQDI++D6oY/jxj/KMlc5Yq9ef1DF4eiRV952Dr2W+rpiaL+qd8MVjB4it1ys/vfXPx3 yWxxFsm7a3LCrjrOWXpK/swRkfB9XCyflmtwS3icE5xyUvlOwReDxeW13zz6LDmDBCWj9/pM OH/d0eCG1ulNAurftdetXZvjd9/7vs3mwkojxs899QtElFiKMxINtZiLihMBiDTwCiADAAA= Cc: kitten@ietf.org, Sam Hartman Subject: Re: [kitten] Comments on draft-ietf-kitten-aes-cts-hmac-sha2-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 03:05:44 -0000 Nico Williams writes: > Some text for the intro section would be nice. And a solution to the > short plaintext problem is critical (if nothing else because GSS > consumers are free to use shorter plaintexts and we don't know if they > do or don't; ditto AFS and other non-Internet protocols). I'm happy > with either a counter or confounded short plaintext encryption > solution, and I'd prefer the counter one on account of performance > (again). As an implementor, I'm reluctant to use any scheme where the short-plaintext case requires a substantially difference code path. Such special cases increase the risk of bugs and interop problems. I'm not sure it's better to reconsider PKCS#7-padded CBC mode with random public IV or confounded CTS mode. From hartmans@mit.edu Thu May 23 20:20:53 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BAB921F960D for ; Thu, 23 May 2013 20:20:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fi6nTBeuhSzo for ; Thu, 23 May 2013 20:20:43 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id E82C421F95C4 for ; Thu, 23 May 2013 20:20:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 5F4BD20618; Thu, 23 May 2013 23:17:31 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cnz3EgfJgij4; Thu, 23 May 2013 23:17:30 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Thu, 23 May 2013 23:17:30 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id E0C0C4206; Thu, 23 May 2013 23:20:31 -0400 (EDT) From: Sam Hartman To: Tom Yu References: <44302EA3-1CB6-4F9A-A6B4-25F5FCDBCC0A@tycho.ncsc.mil> <7E40423E-7040-4AD5-9135-97032369CAC0@tycho.ncsc.mil> Date: Thu, 23 May 2013 23:20:31 -0400 In-Reply-To: (Tom Yu's message of "Thu, 23 May 2013 23:05:30 -0400") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: kitten@ietf.org, Sam Hartman Subject: Re: [kitten] Comments on draft-ietf-kitten-aes-cts-hmac-sha2-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 03:20:53 -0000 >>>>> "Tom" == Tom Yu writes: Tom> Nico Williams writes: >> Some text for the intro section would be nice. And a solution to >> the short plaintext problem is critical (if nothing else because >> GSS consumers are free to use shorter plaintexts and we don't >> know if they do or don't; ditto AFS and other non-Internet >> protocols). I'm happy with either a counter or confounded short >> plaintext encryption solution, and I'd prefer the counter one on >> account of performance (again). I'd like to better understand how GSS consumers contribute to the short-plaintext problem. won't the CFX header always be large enough to get us a block? From nico@cryptonector.com Thu May 23 22:30:15 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E48121F8F24 for ; Thu, 23 May 2013 22:30:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.839 X-Spam-Level: X-Spam-Status: No, score=-1.839 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d02W31Cmqg3z for ; Thu, 23 May 2013 22:30:10 -0700 (PDT) Received: from homiemail-a30.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id F38AA21F8F9E for ; Thu, 23 May 2013 22:30:05 -0700 (PDT) Received: from homiemail-a30.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTP id 5BFB721DE65 for ; Thu, 23 May 2013 22:30:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=wzycX0ujKo1nBzRPJlgC huUnBbE=; b=X+d+gJYntERtv4tdFBpHW4vCA+Kwt07I0D71SK+8K3OExLmL3xaj MFutnYAo8SscBtPjncOzNT8L06PItrCqswYwdrtzygbHdSPcvdCYz6cSWD1bHX2O N6DcAcI6SEWpNr+iVfiBxHBUAYyit47l8sbn13dFT3EpaEih7qXGhto= Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTPSA id 05EC521DE55 for ; Thu, 23 May 2013 22:30:04 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id hi5so4961189wib.12 for ; Thu, 23 May 2013 22:30:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=H2A3pwZ4tY9L7QR/0kW/sypGeoSYUVdaiMSc89TCIKg=; b=SOnFUG+wsIJ8Pr8FnJhVnLdqtKf0/DIvrUflioOf7urMc58UFjxjFzQdVQEonkRaUa O9op+eHTUrTH2MnutDSq5k7ZaJYH1Z0mI5FFnE+tuiSAYLT475whletl+g5csJQLg9f3 tqb5n66PiZ1VA2KFdhgoxl/An4DP71iwge7pETgfgRDID9tcsiwb5YHKR1Fs/TM5UeCN 2HO0Wzgeml/p9MVimjcFOft/t23VhiF7dBOTLAxI/VvH/bm4qOlKB3TgMG6p0nKOllEE qUYubJYxOHNgQYPCOpurCW2vZVZSHXctJ8V9L8MdpleS/r8DMV9hHg6CRdr2MQZMgqIO nO/A== MIME-Version: 1.0 X-Received: by 10.180.189.41 with SMTP id gf9mr30173030wic.32.1369373403202; Thu, 23 May 2013 22:30:03 -0700 (PDT) Received: by 10.216.111.132 with HTTP; Thu, 23 May 2013 22:30:02 -0700 (PDT) In-Reply-To: References: <44302EA3-1CB6-4F9A-A6B4-25F5FCDBCC0A@tycho.ncsc.mil> <7E40423E-7040-4AD5-9135-97032369CAC0@tycho.ncsc.mil> Date: Fri, 24 May 2013 00:30:02 -0500 Message-ID: From: Nico Williams To: Sam Hartman Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org Subject: Re: [kitten] Comments on draft-ietf-kitten-aes-cts-hmac-sha2-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 05:30:15 -0000 On Thu, May 23, 2013 at 10:20 PM, Sam Hartman wrote: > I'd like to better understand how GSS consumers contribute to the > short-plaintext problem. won't the CFX header always be large enough to > get us a block? Oh, indeed! CFX wrap token headers are 16 bytes. KRB-PRIV and AP-REP are the PDUs with the shortest plaintext input to encryption in RFC41210, I think. If I count correctly a 0-byte plaintext can yield a EncKrbPrivPart no shorter than exactly 23 bytes assuming HostAddress types that are no shorter than 4 bytes. As for EncAPRepPart the ctime field (and its tags) along get us past 16 bytes. Hmmm, an EncKrbCredPart with zero KrbCredInfoscould be shorter than 16 bytes, but it'd be senseless. That only leaves non-standard consumers of RFC3961 to worry about. Nico -- From hartmans@mit.edu Fri May 24 05:44:52 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D30CC21F8651 for ; Fri, 24 May 2013 05:44:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rI34hZTFOMHu for ; Fri, 24 May 2013 05:44:45 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id F3C4F21F8EFC for ; Fri, 24 May 2013 05:44:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 51A8620618; Fri, 24 May 2013 08:41:40 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id veB77JnUKKbK; Fri, 24 May 2013 08:41:39 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Fri, 24 May 2013 08:41:39 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 5923E4206; Fri, 24 May 2013 08:44:42 -0400 (EDT) From: Sam Hartman To: Nico Williams References: <44302EA3-1CB6-4F9A-A6B4-25F5FCDBCC0A@tycho.ncsc.mil> <7E40423E-7040-4AD5-9135-97032369CAC0@tycho.ncsc.mil> Date: Fri, 24 May 2013 08:44:42 -0400 In-Reply-To: (Nico Williams's message of "Fri, 24 May 2013 00:30:02 -0500") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: kitten@ietf.org, Sam Hartman Subject: Re: [kitten] Comments on draft-ietf-kitten-aes-cts-hmac-sha2-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 12:44:52 -0000 >>>>> "Nico" == Nico Williams writes: Nico> On Thu, May 23, 2013 at 10:20 PM, Sam Hartman wrote: Nico> That only leaves non-standard consumers of RFC3961 to worry Nico> about. Nico> Nico -- Jeff H has argued that those non-standard consumers are important. I've seen no disagreement here. As chair it sounds like we want to fix the short-plaintext problem. However, it's not sounding like it's going to come up in practice much. I don't know that affects our decision space much, but it seems good to characterize the problem we're solving. we seem to need a solution to short plaintext because it is a specification requirement. It does not seem to be performance critical or often-exercised code. we also want to be careful not to have it be code that becomes often exercised because its bugs are convenient for attackers:-) From ghudson@mit.edu Fri May 24 09:04:32 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39F6821F96A6 for ; Fri, 24 May 2013 09:04:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wcsc6Aod263K for ; Fri, 24 May 2013 09:04:25 -0700 (PDT) Received: from dmz-mailsec-scanner-3.mit.edu (DMZ-MAILSEC-SCANNER-3.MIT.EDU [18.9.25.14]) by ietfa.amsl.com (Postfix) with ESMTP id 8D1D821F9246 for ; Fri, 24 May 2013 09:04:25 -0700 (PDT) X-AuditID: 1209190e-b7f4f6d000005142-dc-519f8f88f372 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id A5.2D.20802.88F8F915; Fri, 24 May 2013 12:04:24 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id r4OG4M5I031999; Fri, 24 May 2013 12:04:23 -0400 Received: from [18.101.8.131] (VPN-18-101-8-131.MIT.EDU [18.101.8.131]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id r4OG4KKf007272 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 24 May 2013 12:04:21 -0400 Message-ID: <519F8F84.7000805@mit.edu> Date: Fri, 24 May 2013 12:04:20 -0400 From: Greg Hudson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Sam Hartman References: <44302EA3-1CB6-4F9A-A6B4-25F5FCDBCC0A@tycho.ncsc.mil> <7E40423E-7040-4AD5-9135-97032369CAC0@tycho.ncsc.mil> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnleLIzCtJLcpLzFFi42IRYrdT1+3onx9o0HlOxuJr2wM2i6ObV7FY nLp2hM2B2ePlqXOMHkuW/GTyWDn1NHsAcxSXTUpqTmZZapG+XQJXxsQ5n5gKXrBX/Jx0hbmB cS5bFyMnh4SAicTDs+tYIGwxiQv31gPFuTiEBPYxSjz+eJAFwtnIKDG/+wFU5giTxMH3H5lA WngF1CR+d61n7GLk4GARUJVY/pkdJMwmoCxx8Ow3sKmiAiESr96fYoMoF5Q4OfMJWFxEQF1i 9aVJYPXMAlYSNz4cYQSxhQU8JB6ufAa1azu7RMv1ZWANnEC7Jm/5AHWqpMSiaZ0sEM06Eu/6 HjBD2PIS29/OYZ7AKDQLyb5ZSMpmISlbwMi8ilE2JbdKNzcxM6c4NVm3ODkxLy+1SNdYLzez RC81pXQTIyjcOSX5djB+Pah0iFGAg1GJh1ewfH6gEGtiWXFl7iFGSQ4mJVHeoD6gEF9Sfkpl RmJxRnxRaU5q8SFGCQ5mJRFesTKgHG9KYmVValE+TEqag0VJnPdKyk1/IYH0xJLU7NTUgtQi mKwMB4eSBG8byFDBotT01Iq0zJwShDQTByfIcB6g4bEgNbzFBYm5xZnpEPlTjIpS4rxzQRIC IImM0jy4Xlg6esUoDvSKMG85SBUPMJXBdb8CGswENPhmLtjgkkSElFQD44Z9nW78Qrsf3e3d c6xM/7nDrZmevZGOM+Kux390XzKtTHpbZbZOX+xP9yOHn+9tL3q1+NY/1282QVZVG8XfJ3b4 l9ovcJpgzzK1PHnC2zN9cwQMjCLWfhCVEP75M2+N92Ol/dKr++2PiEizM746cEJx7oN63yvf AxhvcWS3HrZv3sCroiFTocRSnJFoqMVcVJwIAF4x9zgiAwAA Cc: kitten@ietf.org Subject: Re: [kitten] Comments on draft-ietf-kitten-aes-cts-hmac-sha2-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 16:04:32 -0000 On 05/24/2013 08:44 AM, Sam Hartman wrote: > As chair it sounds like we want to fix the short-plaintext problem. > > However, it's not sounding like it's going to come up in practice much. Perhaps not with protocol data, but it comes up in MIT krb5 when encrypting key data with the master key. Encrypting a DES key in an AES master key is a payload less than the block size (8 < 16); encrypting an AES-128 key is a payload equal to the block size (16 = 16). > we seem to need a solution to short plaintext because it is a > specification requirement. It does not seem to be performance critical > or often-exercised code. Decrypting key data is performance-relevant to KDCs, although my experience is that for short payloads, API overhead competes with block encryption costs. Obviously, using RFC 3961 encryption for key data is an implementation choice. Also note that RFC 3962 has a short plaintext exception for 0-length plaintexts--section 5 paragraphs 3 and 6. From jhutz@cmu.edu Fri May 24 11:40:15 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3F2611E80E4 for ; Fri, 24 May 2013 11:40:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SkPqGS0Fs-xt for ; Fri, 24 May 2013 11:40:10 -0700 (PDT) Received: from smtp01.srv.cs.cmu.edu (SMTP01.SRV.CS.CMU.EDU [128.2.217.196]) by ietfa.amsl.com (Postfix) with ESMTP id CD6F321F9060 for ; Fri, 24 May 2013 11:40:09 -0700 (PDT) Received: from [128.2.193.239] (minbar.fac.cs.cmu.edu [128.2.193.239]) (authenticated bits=0) by smtp01.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id r4OIe7Mb029531 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 24 May 2013 14:40:08 -0400 (EDT) Message-ID: <1369420807.2711.829.camel@minbar.fac.cs.cmu.edu> From: Jeffrey Hutzelman To: Greg Hudson Date: Fri, 24 May 2013 14:40:07 -0400 In-Reply-To: <16429_1369411474_r4OG4XeE016992_519F8F84.7000805@mit.edu> References: <44302EA3-1CB6-4F9A-A6B4-25F5FCDBCC0A@tycho.ncsc.mil> <7E40423E-7040-4AD5-9135-97032369CAC0@tycho.ncsc.mil> <16429_1369411474_r4OG4XeE016992_519F8F84.7000805@mit.edu> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 X-Scanned-By: mimedefang-cmuscs on 128.2.217.196 Cc: kitten@ietf.org, Sam Hartman , jhutz@cmu.edu Subject: Re: [kitten] Comments on draft-ietf-kitten-aes-cts-hmac-sha2-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 18:40:15 -0000 On Fri, 2013-05-24 at 12:04 -0400, Greg Hudson wrote: > On 05/24/2013 08:44 AM, Sam Hartman wrote: > > As chair it sounds like we want to fix the short-plaintext problem. > > > > However, it's not sounding like it's going to come up in practice much. > > Perhaps not with protocol data, but it comes up in MIT krb5 when > encrypting key data with the master key. Encrypting a DES key in an AES > master key is a payload less than the block size (8 < 16); encrypting an > AES-128 key is a payload equal to the block size (16 = 16). > > > we seem to need a solution to short plaintext because it is a > > specification requirement. It does not seem to be performance critical > > or often-exercised code. > > Decrypting key data is performance-relevant to KDCs, although my > experience is that for short payloads, API overhead competes with block > encryption costs. Obviously, using RFC 3961 encryption for key data is > an implementation choice. > > Also note that RFC 3962 has a short plaintext exception for 0-length > plaintexts--section 5 paragraphs 3 and 6. RFC3962's discussion of CTS does indeed include a short plaintext exception. However, this never comes into play, because the enctypes described in that document are based on the simplified profile, which never invokes the underlying cipher with a message shorter than an entire cipher block. When encrypting application data, there is a one-cipher-block confounder. In key derivation, the constant is first n-folded to the block size. This turns out to be important, because key derivation depends on the cipher behaving deterministically, and CTS as described in RFC3962 section 5 is not required to behave deterministically for inputs shorter than one block. -- Jeff From nico@cryptonector.com Fri May 24 11:46:01 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F6D811E80F7 for ; Fri, 24 May 2013 11:46:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3QCXRQIrPjNP for ; Fri, 24 May 2013 11:45:56 -0700 (PDT) Received: from homiemail-a29.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id 94A8621F9051 for ; Fri, 24 May 2013 11:45:56 -0700 (PDT) Received: from homiemail-a29.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTP id 37B67674074 for ; Fri, 24 May 2013 11:45:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=NjqpRU6WX1i7n3HENAbb syVryy4=; b=Iu0PhcZYtHqA9dhiR6GDmdZEV0x4VbRcaiRfDjt+6J38sgoOCKq9 LxCxAFU1UD2Is+f9NfP13dJVPs0ZBdieVfKIDokI9V5hN3PVOQLz0H9LjsbUkLhI 56wqgMw/yX+0F5W8zhKNWaOu1dRGrtd3DaHDL8TuI1I3oDUudD60gfQ= Received: from mail-we0-f179.google.com (mail-we0-f179.google.com [74.125.82.179]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTPSA id 3D1FC674088 for ; Fri, 24 May 2013 11:45:51 -0700 (PDT) Received: by mail-we0-f179.google.com with SMTP id m46so2982212wev.24 for ; Fri, 24 May 2013 11:45:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0tp2xVzw0W53GmCyWbzQFmoVLRz0mH4rE/1p9VkrcuY=; b=psEPjf/iskTgnA8/3tjS6O1c9Kaei0fnAq3KezY54rDt2Dk9aTSACzf/hbqHo7ESxk 6tlZB8/PU9SmGuLZnnbH1cS4tYjvrM0sEXwwTRsFPqpu25dtbRfE5121ItU199ohV9mM ZL8X0HQ++1d8fRSHnNmB87fvtVDCB7/Q2b5AqT6pMb5oil27/hcM5s6gmGCTF4whmGhL EZQyj/g5TwlHiXLRRp1yf48BnEqwT6Zeyq2ps04NO63LorPuEfu/+h2oU65R9zvh5mR6 9QUAoSv0xY2m84LyySFap9ltYQmoyGGNurpgBnSFvZiIHt++EtxtNGTx7mim2zZtTc80 /YgA== MIME-Version: 1.0 X-Received: by 10.194.219.4 with SMTP id pk4mr656435wjc.50.1369421149248; Fri, 24 May 2013 11:45:49 -0700 (PDT) Received: by 10.217.133.83 with HTTP; Fri, 24 May 2013 11:45:49 -0700 (PDT) In-Reply-To: References: <44302EA3-1CB6-4F9A-A6B4-25F5FCDBCC0A@tycho.ncsc.mil> <22606_1369111554_r4L4jrrH023245_CAK3OfOiRsqC1RxbU96OGzOUj0=UEcQbXNKPrhBAgYyybQDHD_Q@mail.gmail.com> <1369154928.2711.772.camel@minbar.fac.cs.cmu.edu> <5F29C375-8261-41B2-B188-1938C6201ABD@tycho.ncsc.mil> <9358351E-D3B6-49E3-B6B0-DDE71D95361C@tycho.ncsc.mil> Date: Fri, 24 May 2013 13:45:49 -0500 Message-ID: From: Nico Williams To: Kelley Burgin Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org, Sam Hartman , "Kevin M. Igoe" , Jeffrey Hutzelman Subject: Re: [kitten] Comments on draft-ietf-kitten-aes-cts-hmac-sha2-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 18:46:01 -0000 On Wed, May 22, 2013 at 10:51 AM, Nico Williams wrote: > As for short-plaintext, I think I prefer Tom's counter mode solution > (again, for performance reasons). And also because it doesn't introduce any ambiguities for us to resolve: if the ciphertext is shorter than 16 bytes then do the counter mode thing, else do CTS. Greg's note makes me nervous about abandoning short plaintext support. Nico -- From tlyu@mit.edu Fri May 24 11:59:19 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07F6211E80AD for ; Fri, 24 May 2013 11:59:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.374 X-Spam-Level: X-Spam-Status: No, score=-103.374 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yHmAyrRq6QcY for ; Fri, 24 May 2013 11:59:03 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (DMZ-MAILSEC-SCANNER-6.MIT.EDU [18.7.68.35]) by ietfa.amsl.com (Postfix) with ESMTP id 7C87811E80A6 for ; Fri, 24 May 2013 11:59:01 -0700 (PDT) X-AuditID: 12074423-b7f826d000001438-5d-519fb875a5c1 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 15.7C.05176.578BF915; Fri, 24 May 2013 14:59:01 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id r4OIwxSS005545; Fri, 24 May 2013 14:59:00 -0400 Received: from cathode-dark-space.mit.edu (CATHODE-DARK-SPACE.MIT.EDU [18.18.1.96]) (authenticated bits=56) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id r4OIwuD8015475 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 24 May 2013 14:58:58 -0400 Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id r4OIwulY026501; Fri, 24 May 2013 14:58:56 -0400 (EDT) To: Nico Williams References: <44302EA3-1CB6-4F9A-A6B4-25F5FCDBCC0A@tycho.ncsc.mil> <22606_1369111554_r4L4jrrH023245_CAK3OfOiRsqC1RxbU96OGzOUj0=UEcQbXNKPrhBAgYyybQDHD_Q@mail.gmail.com> <1369154928.2711.772.camel@minbar.fac.cs.cmu.edu> <5F29C375-8261-41B2-B188-1938C6201ABD@tycho.ncsc.mil> <9358351E-D3B6-49E3-B6B0-DDE71D95361C@tycho.ncsc.mil> From: Tom Yu Date: Fri, 24 May 2013 14:58:56 -0400 In-Reply-To: (Nico Williams's message of "Fri, 24 May 2013 13:45:49 -0500") Message-ID: Lines: 12 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprGKsWRmVeSWpSXmKPExsUixCmqrVu6Y36gwfLd0hZf2x6wWVx/f47d 4ujmVSwWE069ZrWY15BhceraETYHNo/9rcdYPV6eOsfosWTJTyaP/l0vWT1WTj3N7rG1+R9j AFsUl01Kak5mWWqRvl0CV8bh+cfYC74xV5y7t5a1gXEmcxcjB4eEgInEhKu6XYycQKaYxIV7 69m6GLk4hAT2MUr0tb5ihnA2Mkos+LOTCcI5xyTx7tUcVgini1HixpVHrCD9IgKaEtfnLQXr ZxbYziix58gLRpCEsICHxMOVz6AGv2GTeHL0IhvIcjYBaYmji8tAalgEVCV2fnrAAlLDKTCB UeLcxJ0sIAleAQuJn1OWg23gEeCU2D1pKztEXFDi5MwnYDXMAloSN/69ZJrAKDgLSWoWktQC RqZVjLIpuVW6uYmZOcWpybrFyYl5ealFumZ6uZkleqkppZsYQcHP7qK8g/HPQaVDjAIcjEo8 vALl8wOFWBPLiitzDzFKcjApifLabAcK8SXlp1RmJBZnxBeV5qQWH2KU4GBWEuFNXAiU401J rKxKLcqHSUlzsCiJ815LuekvJJCeWJKanZpakFoEk5Xh4FCS4M0EGSpYlJqeWpGWmVOCkGbi 4AQZzgM0vAykhre4IDG3ODMdIn+KUVFKnDcGJCEAksgozYPrhSWnV4ziQK8I88aBVPEAExtc 9yugwUxAg2/mgg0uSURISTUw2j4xavrbuZd3VcLf6RGhH85ZdrseZ5801a3G+U/m6Y3WvUcU j72br+Jbe0twytE9qXeTrBXD+0yvzivN93BvN5UT/XcqMfBTZ03FavuzT+KS/iq8O+K9+4PM pRW8XaYPP6sIP559K23OZPOTEaHyh27daDn3c7/b0226uyv3ac3L83mn/LZNXImlOCPRUIu5 qDgRAFNOtvspAwAA Cc: kitten@ietf.org, Sam Hartman , "Kevin M. Igoe" , Jeffrey Hutzelman Subject: Re: [kitten] Comments on draft-ietf-kitten-aes-cts-hmac-sha2-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 18:59:19 -0000 Nico Williams writes: > On Wed, May 22, 2013 at 10:51 AM, Nico Williams wrote: >> As for short-plaintext, I think I prefer Tom's counter mode solution >> (again, for performance reasons). > > And also because it doesn't introduce any ambiguities for us to > resolve: if the ciphertext is shorter than 16 bytes then do the > counter mode thing, else do CTS. My suggestion didn't involve counter mode, just a different interpretation of CTS. From nico@cryptonector.com Fri May 24 12:31:22 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9B9721E8094 for ; Fri, 24 May 2013 12:31:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GOym-tsuRtvK for ; Fri, 24 May 2013 12:31:17 -0700 (PDT) Received: from homiemail-a24.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id A13BA21E8090 for ; Fri, 24 May 2013 12:31:10 -0700 (PDT) Received: from homiemail-a24.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTP id 2A7A62C806C for ; Fri, 24 May 2013 12:31:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=3T5HX/HGCLWlfmTVaG9v 7GO/SRc=; b=Sm5st9vbC6CjE7wTJefXtOewtWDPE5XTlkXwL7/J0lqTXO8zXz8S Eia5ZKgkK/N1Nik3u6PBRLofn0+qZ/xE4DQ6xpup4vo3hjF613cldBdIJrtN+TzP OdjFvVbkSFe3HA9NY3hf3bODTXaR+OtN435jFSiUf2fJMb44GVaBIhk= Received: from mail-wg0-f41.google.com (mail-wg0-f41.google.com [74.125.82.41]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTPSA id 4CA272C8082 for ; Fri, 24 May 2013 12:30:53 -0700 (PDT) Received: by mail-wg0-f41.google.com with SMTP id k13so716499wgh.4 for ; Fri, 24 May 2013 12:30:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=cuIdFRTt2EB/8dv/aiQueKlnmpEo99fetePHByOIm1U=; b=ZXuQSyfxWHLMrCWbGnIS6y9Q6PFKgfJ1v2hIZKc2OlNrozy1e4igRJXeJtUSdsC+DU KE+ZvacO6SNfxWWio6nYeDjVVsa4BF3uaqpxaBJlcmH4acGaHNMehc/OaASmv+CInw0a wMKiWIWIOWfR/EuRfby7oC9+90FWkuwS7jjBSPcFK+UMF2F08bcNIbJkDhUxEHmHw+vY CqmIdwKkIaFlG/2ipJc1Tf85IQRYdCcl4cArfGn45PVH+1eQP6OAxmAQIKd3IyZ4KmZT EnSW0Vq6ifaZzfqlQmPkN3UsBJ+3Izgtauwr6QhW7Ys11FYkKrhyew8b+QXBEOgPiamp JFGg== MIME-Version: 1.0 X-Received: by 10.180.20.177 with SMTP id o17mr395533wie.52.1369423850718; Fri, 24 May 2013 12:30:50 -0700 (PDT) Received: by 10.217.133.83 with HTTP; Fri, 24 May 2013 12:30:50 -0700 (PDT) In-Reply-To: References: <44302EA3-1CB6-4F9A-A6B4-25F5FCDBCC0A@tycho.ncsc.mil> <22606_1369111554_r4L4jrrH023245_CAK3OfOiRsqC1RxbU96OGzOUj0=UEcQbXNKPrhBAgYyybQDHD_Q@mail.gmail.com> <1369154928.2711.772.camel@minbar.fac.cs.cmu.edu> <5F29C375-8261-41B2-B188-1938C6201ABD@tycho.ncsc.mil> <9358351E-D3B6-49E3-B6B0-DDE71D95361C@tycho.ncsc.mil> Date: Fri, 24 May 2013 14:30:50 -0500 Message-ID: From: Nico Williams To: Tom Yu Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org, Sam Hartman , "Kevin M. Igoe" , Jeffrey Hutzelman Subject: Re: [kitten] Comments on draft-ietf-kitten-aes-cts-hmac-sha2-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 19:31:22 -0000 On Fri, May 24, 2013 at 1:58 PM, Tom Yu wrote: > Nico Williams writes: >> On Wed, May 22, 2013 at 10:51 AM, Nico Williams wrote: >>> As for short-plaintext, I think I prefer Tom's counter mode solution >>> (again, for performance reasons). >> >> And also because it doesn't introduce any ambiguities for us to >> resolve: if the ciphertext is shorter than 16 bytes then do the >> counter mode thing, else do CTS. > > My suggestion didn't involve counter mode, just a different > interpretation of CTS. Ah, I'd lost track. Also, my approach doesn't have the ambiguity I thought it had. From ghudson@mit.edu Fri May 24 12:44:35 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE15021E8099 for ; Fri, 24 May 2013 12:44:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mW5Tu51I+UWY for ; Fri, 24 May 2013 12:44:29 -0700 (PDT) Received: from dmz-mailsec-scanner-8.mit.edu (DMZ-MAILSEC-SCANNER-8.MIT.EDU [18.7.68.37]) by ietfa.amsl.com (Postfix) with ESMTP id 1AE6221E8090 for ; Fri, 24 May 2013 12:44:28 -0700 (PDT) X-AuditID: 12074425-b7f986d00000082c-61-519fc31ce08a Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id 98.7B.02092.C13CF915; Fri, 24 May 2013 15:44:28 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id r4OJiQMs020694; Fri, 24 May 2013 15:44:27 -0400 Received: from [18.101.8.131] (VPN-18-101-8-131.MIT.EDU [18.101.8.131]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id r4OJiPS1001964 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 24 May 2013 15:44:26 -0400 Message-ID: <519FC318.7060801@mit.edu> Date: Fri, 24 May 2013 15:44:24 -0400 From: Greg Hudson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Jeffrey Hutzelman References: <7E40423E-7040-4AD5-9135-97032369CAC0@tycho.ncsc.mil> <16429_1369411474_r4OG4XeE016992_519F8F84.7000805@mit.edu> <1369420807.2711.829.camel@minbar.fac.cs.cmu.edu> In-Reply-To: <1369420807.2711.829.camel@minbar.fac.cs.cmu.edu> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpileLIzCtJLcpLzFFi42IRYrdT0ZU5PD/QYPYlXovr78+xWxzdvIrF gcljf+sxVo8lS34yBTBFcdmkpOZklqUW6dslcGX8ufaYpeA8R8WhB/9YGxh/s3UxcnJICJhI HHh2mB3CFpO4cG89WFxIYB+jxLNvpl2MXED2RkaJJy/vsEA4R5gk5mzZxwpSxSugJrHoziIm EJtFQFViyrSNzCA2m4CyxMGz31hAbFGBEIlX70+xQdQLSpyc+QQsLgJUf2/OLDCbWUBY4sL2 vWAzhQU8JB6ufAZ1xQV2iX9TikBsTgE7iUkt36CulpRYNK0TqJcDqFddYv08IYgx8hLb385h nsAoNAvJtlkIVbOQVC1gZF7FKJuSW6Wbm5iZU5yarFucnJiXl1qka6GXm1mil5pSuokRHNQu qjsYJxxSOsQowMGoxMMrUD4/UIg1say4MvcQoyQHk5Ior+RBoBBfUn5KZUZicUZ8UWlOavEh RgkOZiURXpmdQDnelMTKqtSifJiUNAeLkjjvjZSb/kIC6YklqdmpqQWpRTBZGQ4OJQneqkNA jYJFqempFWmZOSUIaSYOTpDhPEDDOUFqeIsLEnOLM9Mh8qcYFaXEeWeCJARAEhmleXC9sKTz ilEc6BVh3nSQKh5gwoLrfgU0mAlo8M1csMEliQgpqQZGuZlxqdK7KstDT0yKFwn1mal18/ay oPYNR9iVjZOjXdy6lLbLdF9/zT7zytHcz5mXZQWEqq/lmz+64vtI6Jt1wvHP69avm2KxNkJK LPnM/U0PdH//UMp8b/9m6Zb9JtNefH95RfPLgqNKy8q3XHmxYOkk1xCuDG0HlizJ/EdZH5IX sQtIZcz/qsRSnJFoqMVcVJwIAMO4x2oVAwAA Cc: kitten@ietf.org Subject: Re: [kitten] Comments on draft-ietf-kitten-aes-cts-hmac-sha2-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 19:44:35 -0000 On 05/24/2013 02:40 PM, Jeffrey Hutzelman wrote: > RFC3962's discussion of CTS does indeed include a short plaintext > exception. However, this never comes into play, because the enctypes > described in that document are based on the simplified profile, which > never invokes the underlying cipher with a message shorter than an > entire cipher block. But they can invoke the underlying cipher with a message length exactly equal to one cipher block, if the RFC 3961 input length is zero. So the RFC 3962 exceptions for encrypting exactly one block can come into play. (NIST SP800-38A is confusing on whether its algorithms are defined for an input length of exactly one block. The introductory text claims that it specifies "three variants of CBC mode that accept any plaintext input whose bit length is greater than or equal to the block size," but the algorithms don't seem to work for an input equal to the block size. In CBC-CS1-Encrypt, for instance, you get n=1, d=b at step 1, a single cipherblock C[1] at step 3, and then step 4 references C[0] which isn't defined.) From hardjono@mit.edu Tue May 28 10:11:01 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B0CB21F93FB for ; Tue, 28 May 2013 10:11:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.74 X-Spam-Level: X-Spam-Status: No, score=-3.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, GB_I_INVITATION=-2, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vjDkDJAJkY5U for ; Tue, 28 May 2013 10:10:54 -0700 (PDT) Received: from dmz-mailsec-scanner-7.mit.edu (DMZ-MAILSEC-SCANNER-7.MIT.EDU [18.7.68.36]) by ietfa.amsl.com (Postfix) with ESMTP id CB31B21F9605 for ; Tue, 28 May 2013 10:10:51 -0700 (PDT) X-AuditID: 12074424-b7f8c6d0000028c4-56-51a4e51af5f8 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 71.6F.10436.A15E4A15; Tue, 28 May 2013 13:10:50 -0400 (EDT) Received: from outgoing-exchange-1.mit.edu (OUTGOING-EXCHANGE-1.MIT.EDU [18.9.28.15]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id r4SHAnjj012757 for ; Tue, 28 May 2013 13:10:50 -0400 Received: from W92EXEDGE6.EXCHANGE.MIT.EDU (W92EXEDGE6.EXCHANGE.MIT.EDU [18.7.73.28]) by outgoing-exchange-1.mit.edu (8.13.8/8.12.4) with ESMTP id r4SHAhlQ025710 for ; Tue, 28 May 2013 13:10:49 -0400 Received: from OC11EXHUB12.exchange.mit.edu (18.9.3.26) by W92EXEDGE6.EXCHANGE.MIT.EDU (18.7.73.28) with Microsoft SMTP Server (TLS) id 14.2.309.2; Tue, 28 May 2013 13:09:23 -0400 Received: from OC11EXPO24.exchange.mit.edu ([169.254.1.11]) by OC11EXHUB12.exchange.mit.edu ([18.9.3.26]) with mapi id 14.02.0309.002; Tue, 28 May 2013 13:09:43 -0400 From: Thomas Hardjono To: "kitten@ietf.org" Thread-Topic: [security- services] 30-day Public Review for SAML V2.0 Enhanced Client or Proxy Profile V2.0 Thread-Index: Ac5bxiUE6VtvRGhySvaBUambrl8XTQ== Date: Tue, 28 May 2013 17:09:42 +0000 Message-ID: <5E393DF26B791A428E5F003BB6C5342A2F145666@OC11EXPO24.exchange.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [18.189.125.14] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrMKsWRmVeSWpSXmKPExsUixCmqrCv1dEmgwb0OYYujm1exODB6LFny kymAMYrLJiU1J7MstUjfLoEro6nnFUvBSvWKw7eOsTYwTlbsYuTkkBAwkXj9aS8LhC0mceHe erYuRi4OIYF9jBIHlz9ngnCuMUrsWt3MAuHcYZR41LqKHcLZzijx4vxnVghnFVDZ7u/MIMPY BDQkzv3eyw5iiwioS+w9NBWonYNDWCBH4udUdhBTRCBXYvYNfogKPYnuC4vAOlkEVCUWrZnG BGLzCgRJbN66gBXEZgQ67/upNWBxZgFxiVtP5jNBnC0osWj2HmaYF/7tesgGYStK7Pj8gR2i Xkdiwe5PbBC2tsSyha+ZIeYLSpyc+YRlAqPYLCRjZyFpmYWkZRaSlgWMLKsYZVNyq3RzEzNz ilOTdYuTE/PyUot0zfVyM0v0UlNKNzGC4ofdRWUHY/MhpUOMAhyMSjy8FpmLA4VYE8uKK3MP MUpyMCmJ8l58vCRQiC8pP6UyI7E4I76oNCe1+BCjBAezkgjvpZVAOd6UxMqq1KJ8mJQ0B4uS OO/1lJv+QgLpiSWp2ampBalFMFkZDg4lCV6RJ0CNgkWp6akVaZk5JQhpJg5OkOE8QMOzQWp4 iwsSc4sz0yHypxh1Od59nvyOUYglLz8vVUoc4joBkKKM0jy4ObC094pRHOgtYd5VIKN4gCkT btIroCVMQEvEmReDLClJREhJNTD6HvSr6UudyZ8ws20Re2KLzd57M64x2m052u4ucWtmsfH/ a/vMTZ94yvyRnN8TauZ6+F/CkxsP1f4d2PLb1qvQWvPSdf9gBsPYKckF89pUpq3g3JElcGT6 9dBEPundHzl9TVr+yjSfnt1cefC87JzW+aKP/b4+/fRTfC2jxe1qQ5E89alCv5SVWIozEg21 mIuKEwGghQ+yVgMAAA== Subject: [kitten] FW: [security- services] 30-day Public Review for SAML V2.0 Enhanced Client or Proxy Profile V2.0 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2013 17:11:01 -0000 Dear Kitten WG, This might be of interest to the Kitten WG. /thomas/ ____________________________________________ -----Original Message----- From: security-services@lists.oasis-open.org [mailto:security-services@list= s.oasis-open.org] On Behalf Of Chet Ensign Sent: Thursday, May 23, 2013 11:06 AM To: tc-announce@lists.oasis-open.org; members@lists.oasis-open.org; securit= y-services@lists.oasis-open.org Subject: [security-services] 30-day Public Review for SAML V2.0 Enhanced Cl= ient or Proxy Profile V2.0 The OASIS Security Services (SAML) TC [1] members have recently approved a= Committee Specification Draft (CSD) and submitted this specification for 3= 0-day public review: SAML V2.0 Enhanced Client or Proxy Profile Version 2.0 Committee Specificat= ion Draft 01 / Public Review Draft 01 14 May 2013 Specification Overview: The SAML V2.0 Enhanced Client or Proxy profile is a Single Sign-On profile = for use with HTTP, and clients with the capability to directly contact a pr= incipal's identity provider(s) without requiring discovery and redirection = by the service provider, as in the case of a browser. This specification up= dates the original profile by adding support for "Holder of Key" subject co= nfirmation and channel bindings, along with other miscellaneous features in= support of more advanced use cases. Public Review Period: The public review starts 23 May 2013 at 00:00 GMT and ends 22 June 2013 at = 23:59 GMT. This is an open invitation to comment. OASIS solicits feedback from potenti= al users, developers and others, whether OASIS members or not, for the sake= of improving the interoperability and quality of its technical work. URIs: The prose specification document and related files are available here: Editable Source (Authoritative): http://docs.oasis-open.org/security/saml/Post2.0/saml-ecp/v2.0/csprd01/saml= -ecp-v2.0-csprd01.odt HTML: http://docs.oasis-open.org/security/saml/Post2.0/saml-ecp/v2.0/csprd01/saml= -ecp-v2.0-csprd01.html PDF: http://docs.oasis-open.org/security/saml/Post2.0/saml-ecp/v2.0/csprd01/saml= -ecp-v2.0-csprd01.pdf XML schema: http://docs.oasis-open.org/security/saml/Post2.0/saml-ecp/v2.0/csprd01/xsd/ ZIP distribution file (complete): For your convenience, OASIS provides a complete package of the prose specif= ication and related files in a ZIP distribution file. You can download the = ZIP file here: http://docs.oasis-open.org/security/saml/Post2.0/saml-ecp/v2.0/csprd01/saml= -ecp-v2.0-csprd01.zip Additional information about the specification and the OASIS Security Servi= ces (SAML) TC can be found at the TC's public home page: https://www.oasis-open.org/committees/security/ Comments may be submitted to the TC by any person through the use of the OA= SIS TC Comment Facility which can be used by following the instructions on = the TC's "Send A Comment" page, or directly at: https://www.oasis-open.org/committees/comments/index.php?wg_abbrev=3Dsecuri= ty Comments submitted by TC non-members for this work and for other work of th= is TC are publicly archived and can be viewed at: https://lists.oasis-open.org/archives/security-services-comment/ All comments submitted to OASIS are subject to the OASIS Feedback License, = which ensures that the feedback you provide carries the same obligations at= least as the obligations of the TC members. In connection with this public= review of "SAML V2.0 Enhanced Client or Proxy Profile V2.0", we call your = attention to the OASIS IPR Policy [2] applicable especially [3] to the work= of this technical committee. All members of the TC should be familiar with= this document, which may create obligations regarding the disclosure and a= vailability of a member's patent, copyright, trademark and license rights t= hat read on an approved OASIS specification. OASIS invites any persons who know of any such claims to disclose these if = they may be essential to the implementation of the above specification, so = that notice of them may be posted to the notice page for this TC's work. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Additional references: [1] OASIS Security Services (SAML) TC https://www.oasis-open.org/committees/security/ [2] http://www.oasis-open.org/who/intellectualproperty.php [3] http://www.oasis-open.org/committees/security/ipr.php https://www.oasis-open.org/policies-guidelines/ipr#s10.2.2 RF on RAND Mode /chet ---------------- Chet Ensign Director of Standards Development and TC Administration OASIS: Advancing open standards for the information society http://www.oasi= s-open.org Primary: +1 973-996-2298 Mobile: +1 201-341-1393 --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that genera= tes this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php From hardjono@mit.edu Tue May 28 10:11:14 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B63D121F9436 for ; Tue, 28 May 2013 10:11:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.67 X-Spam-Level: X-Spam-Status: No, score=-4.67 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, GB_I_INVITATION=-2, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gnf-dG7hSdnx for ; Tue, 28 May 2013 10:11:08 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (DMZ-MAILSEC-SCANNER-2.MIT.EDU [18.9.25.13]) by ietfa.amsl.com (Postfix) with ESMTP id 337F421F943A for ; Tue, 28 May 2013 10:11:08 -0700 (PDT) X-AuditID: 1209190d-b7f966d000000944-fb-51a4e52b1f05 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id FA.B2.02372.B25E4A15; Tue, 28 May 2013 13:11:07 -0400 (EDT) Received: from outgoing-exchange-2.mit.edu (OUTGOING-EXCHANGE-2.MIT.EDU [18.9.28.16]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id r4SHB6JA003972 for ; Tue, 28 May 2013 13:11:07 -0400 Received: from OC11EXEDGE3.EXCHANGE.MIT.EDU (OC11EXEDGE3.EXCHANGE.MIT.EDU [18.9.3.21]) by outgoing-exchange-2.mit.edu (8.13.8/8.12.4) with ESMTP id r4SHAkBt012656 for ; Tue, 28 May 2013 13:11:06 -0400 Received: from W92EXHUB16.exchange.mit.edu (18.7.73.27) by OC11EXEDGE3.EXCHANGE.MIT.EDU (18.9.3.21) with Microsoft SMTP Server (TLS) id 14.2.309.2; Tue, 28 May 2013 13:10:25 -0400 Received: from OC11EXPO24.exchange.mit.edu ([169.254.1.11]) by W92EXHUB16.exchange.mit.edu ([18.7.73.27]) with mapi id 14.02.0309.002; Tue, 28 May 2013 13:10:37 -0400 From: Thomas Hardjono To: "kitten@ietf.org" Thread-Topic: [security- services] 30-day Public Review for SAML V2.0 Channel Binding Extensions V1.0 Thread-Index: Ac5bxkREPl6EDJs/T3qX7pdqSTU3Zw== Date: Tue, 28 May 2013 17:10:35 +0000 Message-ID: <5E393DF26B791A428E5F003BB6C5342A2F1456D9@OC11EXPO24.exchange.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [18.189.125.14] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrKKsWRmVeSWpSXmKPExsUixG6noqv9dEmgwfuH6hZHN69icWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxrK9e9gK7qtVXNrdwtjA+EGhi5GTQ0LARKL1/35GCFtM4sK9 9WxdjFwcQgL7GCXWbNrMCOFcY5T4+2IBK4TzmlFi+fqrUGXbGSVmvJsFVbaKUeL3kYmsIMPY BDQkzv3eyw5iiwioS+w9NJUFxBYWSJM409HPDBFPl9ja8pURwtaTeLWzCyzOIqAqMafhIxuI zSsQJLF733KwmYxAB34/tYYJxGYWEJe49WQ+E8ThghKLZu9hhnni366HbBC2osSOzx/YIep1 JBbs/sQGYWtLLFv4mhlivqDEyZlPWCYwis1CMnYWkpZZSFpmIWlZwMiyilE2JbdKNzcxM6c4 NVm3ODkxLy+1SNdILzezRC81pXQTIyiGOCV5dzC+O6h0iFGAg1GJh/ei5ZJAIdbEsuLK3EOM khxMSqK8Fx8DhfiS8lMqMxKLM+KLSnNSiw8xSnAwK4nwXloJlONNSaysSi3Kh0lJc7AoifNe SbnpLySQnliSmp2aWpBaBJOV4eBQkuAVeQLUKFiUmp5akZaZU4KQZuLgBBnOAzT8I8hi3uKC xNzizHSI/ClGXY53nye/YxRiycvPS5US5xUCGSQAUpRRmgc3B5b6XjGKA70lzBv6CKiKB5g2 4Sa9AlrCBLREnHkxyJKSRISUVAOjZUVrfqnewtupBSVe5+OVPOq/+W765uy14OskB7W2W50W D3XPPF5VuN7R7/DrNLbDm38Xh4VINmmc+/asmZ1Z41FUYNyvDV8vdkY5HQq2jPE6bpHwwa63 9vzmxS/T42fu3P/yxYMfnz/OPv79eo1gG++rmQyHFFsyu+Z8z5R5ePbMBZ3lUkW3lViKMxIN tZiLihMB/MjmKlgDAAA= Subject: [kitten] FW: [security- services] 30-day Public Review for SAML V2.0 Channel Binding Extensions V1.0 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2013 17:11:14 -0000 Dear Kitten WG, This might be of interest to the Kitten WG. /thomas/ ____________________________________________ -----Original Message----- From: security-services@lists.oasis-open.org [mailto:security-services@list= s.oasis-open.org] On Behalf Of Chet Ensign Sent: Thursday, May 23, 2013 11:06 AM To: tc-announce@lists.oasis-open.org; members@lists.oasis-open.org; securit= y-services@lists.oasis-open.org Subject: [security-services] 30-day Public Review for SAML V2.0 Channel Bin= ding Extensions V1.0 The OASIS Security Services (SAML) TC [1] members have recently approved a= Committee Specification Draft (CSD) and submitted this specification for 3= 0-day public review: SAML V2.0 Channel Binding Extensions Version 1.0 Committee Specification Dr= aft 01 / Public Review Draft 01 14 May 2013 Specification Overview: This specification defines an extension to the SAML V2.0 protocol specifica= tion that supports the use of channel bindings in conjunction with SAML pro= files. It also includes a new SAML profile that applies the extension to a = set of profiles that fit a particular communication pattern. Public Review Period: The public review starts 24 May 2013 at 00:00 GMT and ends 23 June 2013 at = 23:59 GMT. This is an open invitation to comment. OASIS solicits feedback from potenti= al users, developers and others, whether OASIS members or not, for the sake= of improving the interoperability and quality of its technical work. URIs: The prose specification document and related files are available here: Editable Source (Authoritative): http://docs.oasis-open.org/security/saml/Post2.0/saml-channel-binding-ext/v= 1.0/csprd01/saml-channel-binding-ext-v1.0-csprd01.odt HTML: http://docs.oasis-open.org/security/saml/Post2.0/saml-channel-binding-ext/v= 1.0/csprd01/saml-channel-binding-ext-v1.0-csprd01.html PDF: http://docs.oasis-open.org/security/saml/Post2.0/saml-channel-binding-ext/v= 1.0/csprd01/saml-channel-binding-ext-v1.0-csprd01.pdf XML schema: http://docs.oasis-open.org/security/saml/Post2.0/saml-channel-binding-ext/v= 1.0/csprd01/xsd/ ZIP distribution file (complete): For your convenience, OASIS provides a complete package of the prose specif= ication and related files in a ZIP distribution file. You can download the = ZIP file here: http://docs.oasis-open.org/security/saml/Post2.0/saml-channel-binding-ext/v= 1.0/csprd01/saml-channel-binding-ext-v1.0-csprd01.zip Additional information about the specification and the OASIS Security Servi= ces (SAML) TC can be found at the TC's public home page: https://www.oasis-open.org/committees/security/ Comments may be submitted to the TC by any person through the use of the OA= SIS TC Comment Facility which can be used by following the instructions on = the TC's "Send A Comment" page, or directly at: https://www.oasis-open.org/committees/comments/index.php?wg_abbrev=3Dsecuri= ty Comments submitted by TC non-members for this work and for other work of th= is TC are publicly archived and can be viewed at: https://lists.oasis-open.org/archives/security-services-comment/ All comments submitted to OASIS are subject to the OASIS Feedback License, = which ensures that the feedback you provide carries the same obligations at= least as the obligations of the TC members. In connection with this public= review of "SAML V2.0 Channel Binding Extensions Version 1.0", we call your= attention to the OASIS IPR Policy [2] applicable especially [3] to the wor= k of this technical committee. All members of the TC should be familiar wit= h this document, which may create obligations regarding the disclosure and = availability of a member's patent, copyright, trademark and license rights = that read on an approved OASIS specification. OASIS invites any persons who know of any such claims to disclose these if = they may be essential to the implementation of the above specification, so = that notice of them may be posted to the notice page for this TC's work. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Additional references: [1] OASIS Security Services (SAML) TC https://www.oasis-open.org/committees/security/ [2] http://www.oasis-open.org/who/intellectualproperty.php [3] http://www.oasis-open.org/committees/security/ipr.php https://www.oasis-open.org/policies-guidelines/ipr#s10.2.2 RF on RAND Mode /chet ---------------- Chet Ensign Director of Standards Development and TC Administration OASIS: Advancing open standards for the information society http://www.oasi= s-open.org Primary: +1 973-996-2298 Mobile: +1 201-341-1393 --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that genera= tes this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php From nico@cryptonector.com Tue May 28 12:34:58 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B118D11E80FD for ; Tue, 28 May 2013 12:34:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.777 X-Spam-Level: X-Spam-Status: No, score=-0.777 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_12=0.6, J_CHICKENPOX_42=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L7415XkwTWXl for ; Tue, 28 May 2013 12:34:53 -0700 (PDT) Received: from homiemail-a26.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id A052A11E80F9 for ; Tue, 28 May 2013 12:34:53 -0700 (PDT) Received: from homiemail-a26.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTP id 47D94B806B for ; Tue, 28 May 2013 12:34:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:date:message-id:subject:from:to:cc:content-type; s= cryptonector.com; bh=DP07Pwu6AZkQodL3P4ge2wKCgb0=; b=hu5O0lgwS/C MEtPLrKy6gkH08L2tJqFhwaQFjyg5h00D0PxtGurgJOeDjmp+xGtfWpYpBDieT29 inmzmjDj/mtgyP9uXcCF18PuqSyTv4lQ5QOsgwAaezeUr+dEMO62tKwJaEcy1bet 3s6vK3iJqGxSu4RFoAuS/S1XI6HUdCNI= Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTPSA id C018EB805B for ; Tue, 28 May 2013 12:34:51 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id k13so5831583wgh.29 for ; Tue, 28 May 2013 12:34:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=mIbwIusrToPRLWpQHG00xCicDtfkDdLh2/YFDFARjFo=; b=RhMyppm0TLFRzzzLhaAFViwk8jl/R5QUgBsd2w4EjEuI49m73g8boIkaNGYNq3syum KM8TGCqwYrD7Y90Fvo3iaF70y37qmtGA9ZRXXxvQgNYfwGNczSriMNwVogj409HU/Oci 3tEIz3x19lN42WbcbszlcygJLO7kEoUuhM80ytHYbCx21dGuvoIrs4HjcYuCB1RxqU0i l8u4J+ifU6HY4hgfaOOnBF7sixIyzKQ9qRcjOF3MxfB89rjklKxW56+f50e0hNdIoidg cD1Mqc6t9gAOBQskancM6QImd/M1WFew91ES4GOvrBBxBSKzj5cslm/DZgwqJtX12q7R 0S6Q== MIME-Version: 1.0 X-Received: by 10.180.185.244 with SMTP id ff20mr13612048wic.0.1369769690187; Tue, 28 May 2013 12:34:50 -0700 (PDT) Received: by 10.216.63.136 with HTTP; Tue, 28 May 2013 12:34:50 -0700 (PDT) Date: Tue, 28 May 2013 14:34:50 -0500 Message-ID: From: Nico Williams To: Tom Yu Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org, Sam Hartman Subject: [kitten] Random-IV and short-plaintexts (Re: Comments on draft-ietf-kitten-aes-cts-hmac-sha2-00) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2013 19:34:58 -0000 On Mon, May 20, 2013 at 5:37 PM, Tom Yu wrote: > I think CTS will work if you are willing to modify the "IV" sent when > the plaintext length is less than or equal to the block size; > basically treat the IV as the next to last block of CBC ciphertext, > truncating it to the length of the plaintext, and send the final block > of CBC ciphertext as the "IV". I really like this. It might even be possible to minimize the code path difference for short plaintexts too. So the short-pt encryption case becomes: - pad pt with zeros - XOR with IV (cipherState XOR nonce) - encrypt (it's just ECB here, as it's only one block) - truncate the pad count of bytes from the ciphertext block and replace the corresponding bytes of the nonce with those - apply the HMAC to the modified nonce and short ciphertext The short-pt decryption case is trivial to work out from the above: - first verify the integrity tag - then reconstitute the block of ciphertext - decrypt - XOR with the nonce (which still has pad-count bytes from the ciphertext) - reconstitute the nonce (using pad-count bytes from the plaintext resulting from the decryption) - update cipherState - truncate the plaintext to the original length Note that 0-length and 1-block-long plaintexts are degenerate cases of this. And there's enough similarity to CTS that it might be possible to make the code path differences for short and long plaintexts minute. Re-writing this to fit in section 6 notation: L(x) = length of x < = less-than operator; true == 1, false == 0 zeroblock = one block (length c) of zeros o[start:len] = sub-string operation returning the substring of length len of string o starting at byte start (zero-based) encryption function PC = (L(P) < c) * (c - L(P)) P' = P | zeroblock[0:PC] N = random nonce of length c (128 bits) IV = N XOR cipherState C = E(Ke, P', IV) using CBC-CS3-Encrypt defined in [SP800-38A+] N' = N[0:c - PC] | C[c - PC:PC] H = HMAC(Ki, N' | C) ciphertext = N' | C | H[1..h] cipherState = N decryption function (N', C, H) = ciphertext PC = (L(C) < c) * (c - L(C)) if (H != HMAC(Ki, N' | C)[1..h]) stop, report error if (PC > 0) IV = zeroblock else IV = N' XOR cipherState P' = D(Ke, C, IV) using CBC-CS3-Decrypt defined in [SP800-38A+] if (PC > 0) IV = (N'[0:c - PC] | P'[c - PC:PC]) N = IV XOR cipherState P = (P' XOR IV)[0:c - PC] else P = P' N = N' cipherState = N Style nit: the I-D refers to "cipher state", "cipherstate", and "cipherState", but all seem to be the same thing. This is confusing. Pick a single spelling and stick with it. I recommend "cipherState" as that makes it clearer that we're talking about a quantity that's specific to this enctype. Style nit: using "+" to mean XOR and then having a parenthetical to clarify this seems silly. Might as well just say XOR :) Nico -- From kwburgi@tycho.ncsc.mil Wed May 29 07:46:14 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3C9A21F882A for ; Wed, 29 May 2013 07:46:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.799 X-Spam-Level: X-Spam-Status: No, score=-8.799 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_21=0.6, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7t91PbmJo830 for ; Wed, 29 May 2013 07:46:07 -0700 (PDT) Received: from nsa.gov (emvm-gh1-uea09.nsa.gov [63.239.67.10]) by ietfa.amsl.com (Postfix) with ESMTP id 60C6721F87C3 for ; Wed, 29 May 2013 07:46:06 -0700 (PDT) X-TM-IMSS-Message-ID: <502f681f000f1022@nsa.gov> Received: from tarius.tycho.ncsc.mil ([144.51.31.2]) by nsa.gov ([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1) id 502f681f000f1022 ; Wed, 29 May 2013 10:49:45 -0400 Received: from rd6um-58422h.infosec.tycho.ncsc.mil (rd6um-58422h [192.168.26.151]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id r4TEjxg5001226; Wed, 29 May 2013 10:46:01 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Kelley Burgin In-Reply-To: Date: Wed, 29 May 2013 10:50:05 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <1AC28877-6470-4F3B-BCAC-A766D0322412@tycho.ncsc.mil> References: To: Nico Williams X-Mailer: Apple Mail (2.1084) Cc: kitten@ietf.org, Sam Hartman Subject: Re: [kitten] Random-IV and short-plaintexts (Re: Comments on draft-ietf-kitten-aes-cts-hmac-sha2-00) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 14:46:14 -0000 This looks good to me, with a couple of comments below.=20 On May 28, 2013, at 3:34 PM, Nico Williams wrote: > Re-writing this to fit in section 6 notation: >=20 > L(x) =3D length of x > < =3D less-than operator; true =3D=3D 1, false =3D=3D 0 > zeroblock =3D one block (length c) of zeros > o[start:len] =3D sub-string operation returning the substring of = length > len of string o starting at byte start (zero-based) >=20 > encryption function PC =3D (L(P) < c) * (c - L(P)) > P' =3D P | zeroblock[0:PC] > N =3D random nonce of length c (128 bits) > IV =3D N XOR cipherState > C =3D E(Ke, P', IV) > using CBC-CS3-Encrypt defined > in [SP800-38A+] > N' =3D N[0:c - PC] | C[c - PC:PC] Shouldn't you mac and send C[0:c - PC] instead of C? (L(C) =3D c since = L(P') =3D c) > H =3D HMAC(Ki, N' | C) > ciphertext =3D N' | C | H[1..h] > cipherState =3D N >=20 > decryption function (N', C, H) =3D ciphertext > PC =3D (L(C) < c) * (c - L(C)) > if (H !=3D HMAC(Ki, N' | C)[1..h]) > stop, report error > if (PC > 0) > IV =3D zeroblock > else > IV =3D N' XOR cipherState > P' =3D D(Ke, C, IV) If you do only send C[0:c - PC], you'll have to reconstruct C before you = get here. C' =3D C | N'[c - PC:PC] > using CBC-CS3-Decrypt defined > in [SP800-38A+] > if (PC > 0) Unless I've missed something, or confused myself with notation, at this = point: P' =3D P xor IV[0:c - PC] | IV[c - PC:PC]. (this is the real IV) > IV =3D (N'[0:c - PC] | P'[c - PC:PC]) So here, IV =3D N[0:c - PC | IV[c - PC:PC] > N =3D IV XOR cipherState and here N =3D IV[0:c - PC] | N[c - PC:PC]. You could fix this by doing: P'' =3D P' XOR cipherState (=3D P+N[0:c - PC] | N[c - PC:PC] P =3D P''[0:c - PC] xor N'[0:c - PC] (these two lines could be combined = into one) N =3D (P | zeroblock[0:PC]) xor P'' > P =3D (P' XOR IV)[0:c - PC] > else > P =3D P' > N =3D N' > cipherState =3D N >=20 > Style nit: the I-D refers to "cipher state", "cipherstate", and > "cipherState", but all seem to be the same thing. This is confusing. > Pick a single spelling and stick with it. I recommend "cipherState" > as that makes it clearer that we're talking about a quantity that's > specific to this enctype. >=20 > Style nit: using "+" to mean XOR and then having a parenthetical to > clarify this seems silly. Might as well just say XOR :) Sounds good - thanks. >=20 > Nico > -- From david.black@emc.com Wed May 29 07:43:51 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F51E21F9007; Wed, 29 May 2013 07:43:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7J-yaSf0WNTd; Wed, 29 May 2013 07:43:45 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id D909321F8D31; Wed, 29 May 2013 07:43:39 -0700 (PDT) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r4TEhRAi023690 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 May 2013 10:43:38 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd05.lss.emc.com [10.254.222.129]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Wed, 29 May 2013 10:43:07 -0400 Received: from mxhub05.corp.emc.com (mxhub05.corp.emc.com [128.222.70.202]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r4TEh6qB008150; Wed, 29 May 2013 10:43:06 -0400 Received: from mx15a.corp.emc.com ([169.254.1.184]) by mxhub05.corp.emc.com ([128.222.70.202]) with mapi; Wed, 29 May 2013 10:43:05 -0400 From: "Black, David" To: "kitten@ietf.org" Date: Wed, 29 May 2013 10:43:04 -0400 Thread-Topic: Kerberos Considerations for iSCSI Authentication Thread-Index: Ac5cetOj5lUqLotRRMCSm1pg3XhHmw== Message-ID: <8D3D17ACE214DC429325B2B98F3AE71296A3C67D@MX15A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 X-Mailman-Approved-At: Wed, 29 May 2013 09:03:25 -0700 Cc: "Black, David" , "storm@ietf.org" Subject: [kitten] Kerberos Considerations for iSCSI Authentication X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 14:43:51 -0000 The storm WG's consolidated iSCSI draft (draft-ietf-storm-iscsi-cons-08) has a few issues from IESG evaluation that need attention, one of which is that some security considerations text for Kerberos needs to be added. I don't know of any Kerberos authentication for iSCSI that's currently in use, although it has been implemented at least once, and hence the decision has been made to retain its specification as part of the iSCSI protocol update in this draft. I'd appreciate comments on the following text, and please at least cc: me (preferably also the storm mailing list). Note that KRB_AP_REQ and KRB_AP_REP are the client message and server's response message as defined in RFC 4120. I do want to head off one area of comments - please send any "you should use GSS-API" comments to /dev/null. iSCSI was specified to use Kerberos w/o GSS-API a long time ago, so GSS-API for iSCSI would be a new iSCSI authentication mechanism that should be in a separate draft, as opposed to this update (which is already long enough). ------------------ 9.2.3 Kerberos Considerations for iSCSI Authentication =20 iSCSI uses Kerberos via "bare" tokens - i.e. does not use GSS-API ([RFC4121= ]) - for authenticating the two Kerberos principals during the iSCSI Login proce= ss. This implies that iSCSI implementations supporting the KRB5 AuthMethod (Section 12.1) are directly involved in the Kerberos protocol. Specifically= , the following actions MUST be performed as specified in [RFC4120]: - Target MUST validate the KRB_AP_REQ to ensure that the initiator can be trusted - When mutual authentication is selected, the initiator MUST validate KRB_AP_REP to determine the outcome of mutual authentication =20 As Kerberos V5 is capable of providing mutual authentication, implementatio= ns SHOULD support mutual authentication by default for login authentication. Note however that Kerberos authentication only assures that the server (iSCSI target) can be trusted by the Kerberos client (initiator) and vice-versa; an initiator should employ appropriately secured service discovery techniques (e.g. iSNS, Section 4.2.7) to ensure that it is talking to the intended target principal. ------------------ Thanks, --David (storm WG co-chair) ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-778= 6 david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 ---------------------------------------------------- From nico@cryptonector.com Wed May 29 10:14:43 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50B2121F9749 for ; Wed, 29 May 2013 10:14:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.423 X-Spam-Level: X-Spam-Status: No, score=0.423 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_12=0.6, J_CHICKENPOX_21=0.6, J_CHICKENPOX_42=0.6, J_CHICKENPOX_91=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z-p7FZpOwX1I for ; Wed, 29 May 2013 10:14:38 -0700 (PDT) Received: from homiemail-a98.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id D32DC21F9729 for ; Wed, 29 May 2013 10:14:35 -0700 (PDT) Received: from homiemail-a98.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a98.g.dreamhost.com (Postfix) with ESMTP id 73E8E2C207D for ; Wed, 29 May 2013 10:14:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=R3oroWTO7dq0CZUS1Wgj f8UnD8Y=; b=lMF217Mh7SS5PrmhS9fpYdC+3YP2rFlbgfE/5JqJpb2g7j4Cz4m+ y7/A/vsgjQenAwRdgs2nxIK06jYuKTNm8teE6pa1Mq7lYh02ONZd/oFDXITsdAOr U3WEUuBKRLWVAmlH7aUedGoiVZpVxYXouCPOsjYUPiw6kwYhXoYA5qc= Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a98.g.dreamhost.com (Postfix) with ESMTPSA id 192D62C207C for ; Wed, 29 May 2013 10:14:31 -0700 (PDT) Received: by mail-wi0-f180.google.com with SMTP id hn14so3730012wib.7 for ; Wed, 29 May 2013 10:14:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1RCLqa0hMsdA+3M5B4jsrjJRTe3MOAdYrhar9kx/Jvk=; b=VDrw2z23vPV0zBfrJsGq0xb2Z6N4+8Q6D+F9u5jtrtRQzfmZ6Ul2iislkMvRFSOi8s OWRsjw100f6vW6Rrq251WYlA5BuKlvFqUVsMn9YpmSG+CRoFlfsO0TwI/kWDqtkf38Fl OFQgtpf4W/o5s0x/9aaO9c4OPEqgIOPkfeDGAQOouUunWhy6NkiaobQVAd9j8rUhAYKZ O370isbrO5FINthx7pU1Y3VAyToiJJTaFh+3ycDhYz9B3u5feq756wnEbI/wr/Gs70FE YSOxOnzZ08VNRpkpU2OcMF5itNuC4QT9WHX4GdOVJgcHg9mlRISx8Iv7CAfgOdLQxgOH xv9w== MIME-Version: 1.0 X-Received: by 10.180.183.139 with SMTP id em11mr15780113wic.16.1369847670287; Wed, 29 May 2013 10:14:30 -0700 (PDT) Received: by 10.216.63.136 with HTTP; Wed, 29 May 2013 10:14:30 -0700 (PDT) In-Reply-To: <1AC28877-6470-4F3B-BCAC-A766D0322412@tycho.ncsc.mil> References: <1AC28877-6470-4F3B-BCAC-A766D0322412@tycho.ncsc.mil> Date: Wed, 29 May 2013 12:14:30 -0500 Message-ID: From: Nico Williams To: Kelley Burgin Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org, Sam Hartman Subject: Re: [kitten] Random-IV and short-plaintexts (Re: Comments on draft-ietf-kitten-aes-cts-hmac-sha2-00) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 17:14:43 -0000 On Wed, May 29, 2013 at 9:50 AM, Kelley Burgin wrote: > This looks good to me, with a couple of comments below. Oh dear, I meant to define C' and use that in the HMAC input. Dunno how I forgot. > On May 28, 2013, at 3:34 PM, Nico Williams wrote: > >> Re-writing this to fit in section 6 notation: >> >> L(x) = length of x >> < = less-than operator; true == 1, false == 0 >> zeroblock = one block (length c) of zeros >> o[start:len] = sub-string operation returning the substring of length >> len of string o starting at byte start (zero-based) >> >> encryption function PC = (L(P) < c) * (c - L(P)) >> P' = P | zeroblock[0:PC] >> N = random nonce of length c (128 bits) >> IV = N XOR cipherState >> C = E(Ke, P', IV) >> using CBC-CS3-Encrypt defined >> in [SP800-38A+] >> N' = N[0:c - PC] | C[c - PC:PC] > > Shouldn't you mac and send C[0:c - PC] instead of C? (L(C) = c since L(P') = c) Yes. I got sloppy there. +>> C' = C[0:c - PC] ->> H = HMAC(Ki, N' | C) +>> H = HMAC(Ki, N' | C') ->> ciphertext = N' | C | H[1..h] +>> ciphertext = N' | C' | H[1..h] >> cipherState = N I also had to be consistent about matching ' usage in the encrypt and decrypt side. Let's make N', P', and C' match on both side, and let's add an IV' on the decrypt side ->>decryption function (N', C, H) = ciphertext +>>decryption function (N', C', H) = ciphertext ->> PC = (L(C) < c) * (c - L(C)) +>> PC = (L(C') < c) * (c - L(C')) ->> if (H != HMAC(Ki, N' | C)[1..h]) +>> if (H != HMAC(Ki, N' | C')[1..h]) >> stop, report error >> if (PC > 0) ->> IV = zeroblock +>> IV' = zeroblock +>> C = C' | N[c - PC:PC] >> else >> IV = N' XOR cipherState +>> C = C' >> P' = D(Ke, C, IV) +>> if (PC > 0) >> P = P'[0:c - PC] >> else > Unless I've missed something, or confused myself with notation, at this point: > P' = P xor IV[0:c - PC] | IV[c - PC:PC]. (this is the real IV) > >> IV = (N'[0:c - PC] | P'[c - PC:PC]) > > So here, IV = N[0:c - PC | IV[c - PC:PC] Earlier if PC > 0 we set IV to be the zeroblock, so that's not quite right. We're reversing the encryption side where we encrypted a zero-padded plaintext, and since XOR zero is the identity function the trailing c-PC:PC bytes of P' will be the trailing bytes of the original IV (which we still need so we can recover N and update the cipherState). Let me see if I can put this together without errors this time, and maybe I can clarify the IV recovery: L(x) = length of x < = less-than operator; true == 1, false == 0 zeroblock = one block (length c) of zeros o[start:len] = sub-string operation returning the substring of length len of string o starting at byte start (zero-based) encryption function PC = (L(P) < c) * (c - L(P)) P' = P | zeroblock[0:PC] N = random nonce of length c (128 bits) IV = N XOR cipherState C = E(Ke, P', IV) using CBC-CS3-Encrypt defined in [SP800-38A+] N' = N[0:c - PC] | C[c - PC:PC] C' = C[0:c - PC] H = HMAC(Ki, N' | C') ciphertext = N' | C' | H[1..h] cipherState = N decryption function (N', C', H) = ciphertext PC = (L(C') < c) * (c - L(C')) if (H != HMAC(Ki, N' | C')[1..h]) stop, report error if (PC > 0) IV' = zeroblock C = C' | N[c - PC:PC] else IV' = N' XOR cipherState C = C' P' = D(Ke, C, IV') using CBC-CS3-Decrypt defined in [SP800-38A+] if (PC > 0) // IV = (N'[0:c - PC] | zeroblock[c - PC:PC]) XOR // (zeroblock[0:c - PC] | P'[c - PC:PC]) IV = (N'[0:c - PC] | P'[c - PC:PC]) N = IV XOR cipherState P = (P' XOR IV)[0:c - PC] else IV = IV' // but we no longer need this P = P' N = N' cipherState = N The decrypt side is tricky to get right :) Have at it. I'm sure I still slipped up. Nico -- From kwburgi@tycho.ncsc.mil Wed May 29 10:32:01 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7545D21F8491 for ; Wed, 29 May 2013 10:32:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.499 X-Spam-Level: X-Spam-Status: No, score=-8.499 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_21=0.6, J_CHICKENPOX_42=0.6, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EztWO7GzxZGS for ; Wed, 29 May 2013 10:31:55 -0700 (PDT) Received: from nsa.gov (emvm-gh1-uea09.nsa.gov [63.239.67.10]) by ietfa.amsl.com (Postfix) with ESMTP id B331021F855F for ; Wed, 29 May 2013 10:31:54 -0700 (PDT) X-TM-IMSS-Message-ID: <50c72b41000f4621@nsa.gov> Received: from tarius.tycho.ncsc.mil ([144.51.31.2]) by nsa.gov ([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1) id 50c72b41000f4621 ; Wed, 29 May 2013 13:35:31 -0400 Received: from rd6um-58422h.infosec.tycho.ncsc.mil (rd6um-58422h [192.168.26.151]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id r4THVmEc001150; Wed, 29 May 2013 13:31:48 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Kelley Burgin In-Reply-To: Date: Wed, 29 May 2013 13:35:54 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1AC28877-6470-4F3B-BCAC-A766D0322412@tycho.ncsc.mil> To: Nico Williams X-Mailer: Apple Mail (2.1084) Cc: kitten@ietf.org, Sam Hartman Subject: Re: [kitten] Random-IV and short-plaintexts (Re: Comments on draft-ietf-kitten-aes-cts-hmac-sha2-00) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 17:32:01 -0000 I still have a question about the decrypt: seems like=20 IV =3D (N'[0:c - PC] | P'[c - PC:PC]) is really N[0:c - PC] | IV[c - = PC:PC]), not the original IV. Did I miss something?=20 As you point out, we don't actually need to recover the IV (just N), so = we can compute the plaintext P directly from P' by (if I didn't mess = up): P =3D (P' XOR cipherState XOR N')[0:c - PC] On May 29, 2013, at 1:14 PM, Nico Williams wrote: > On Wed, May 29, 2013 at 9:50 AM, Kelley Burgin = wrote: >> This looks good to me, with a couple of comments below. >=20 > Oh dear, I meant to define C' and use that in the HMAC input. Dunno > how I forgot. >=20 >> On May 28, 2013, at 3:34 PM, Nico Williams wrote: >>=20 >>> Re-writing this to fit in section 6 notation: >>>=20 >>> L(x) =3D length of x >>> < =3D less-than operator; true =3D=3D 1, false =3D=3D 0 >>> zeroblock =3D one block (length c) of zeros >>> o[start:len] =3D sub-string operation returning the substring of = length >>> len of string o starting at byte start (zero-based) >>>=20 >>> encryption function PC =3D (L(P) < c) * (c - L(P)) >>> P' =3D P | zeroblock[0:PC] >>> N =3D random nonce of length c (128 bits) >>> IV =3D N XOR cipherState >>> C =3D E(Ke, P', IV) >>> using CBC-CS3-Encrypt defined >>> in [SP800-38A+] >>> N' =3D N[0:c - PC] | C[c - PC:PC] >>=20 >> Shouldn't you mac and send C[0:c - PC] instead of C? (L(C) =3D c = since L(P') =3D c) >=20 > Yes. I got sloppy there. >=20 > +>> C' =3D C[0:c - PC] > ->> H =3D HMAC(Ki, N' | C) > +>> H =3D HMAC(Ki, N' | C') >=20 > ->> ciphertext =3D N' | C | H[1..h] > +>> ciphertext =3D N' | C' | H[1..h] >>> cipherState =3D N >=20 > I also had to be consistent about matching ' usage in the encrypt and > decrypt side. Let's make N', P', and C' match on both side, and let's > add an IV' on the decrypt side >=20 > ->>decryption function (N', C, H) =3D ciphertext > +>>decryption function (N', C', H) =3D ciphertext > ->> PC =3D (L(C) < c) * (c - L(C)) > +>> PC =3D (L(C') < c) * (c - L(C')) > ->> if (H !=3D HMAC(Ki, N' | C)[1..h]) > +>> if (H !=3D HMAC(Ki, N' | C')[1..h]) >>> stop, report error >>> if (PC > 0) > ->> IV =3D zeroblock > +>> IV' =3D zeroblock > +>> C =3D C' | N[c - PC:PC] >>> else >>> IV =3D N' XOR cipherState > +>> C =3D C' >>> P' =3D D(Ke, C, IV) > +>> if (PC > 0) >>> P =3D P'[0:c - PC] >>> else >=20 >> Unless I've missed something, or confused myself with notation, at = this point: >> P' =3D P xor IV[0:c - PC] | IV[c - PC:PC]. (this is the real IV) >>=20 >>> IV =3D (N'[0:c - PC] | P'[c - PC:PC]) >>=20 >> So here, IV =3D N[0:c - PC | IV[c - PC:PC] >=20 > Earlier if PC > 0 we set IV to be the zeroblock, so that's not quite > right. We're reversing the encryption side where we encrypted a > zero-padded plaintext, and since XOR zero is the identity function the > trailing c-PC:PC bytes of P' will be the trailing bytes of the > original IV (which we still need so we can recover N and update the > cipherState). >=20 > Let me see if I can put this together without errors this time, and > maybe I can clarify the IV recovery: >=20 > L(x) =3D length of x > < =3D less-than operator; true =3D=3D 1, false =3D=3D 0 > zeroblock =3D one block (length c) of zeros > o[start:len] =3D sub-string operation returning the substring of = length > len of string o starting at byte start (zero-based) >=20 > encryption function PC =3D (L(P) < c) * (c - L(P)) > P' =3D P | zeroblock[0:PC] > N =3D random nonce of length c (128 bits) > IV =3D N XOR cipherState > C =3D E(Ke, P', IV) > using CBC-CS3-Encrypt defined > in [SP800-38A+] > N' =3D N[0:c - PC] | C[c - PC:PC] > C' =3D C[0:c - PC] > H =3D HMAC(Ki, N' | C') > ciphertext =3D N' | C' | H[1..h] > cipherState =3D N >=20 > decryption function (N', C', H) =3D ciphertext > PC =3D (L(C') < c) * (c - L(C')) > if (H !=3D HMAC(Ki, N' | C')[1..h]) > stop, report error > if (PC > 0) > IV' =3D zeroblock > C =3D C' | N[c - PC:PC] > else > IV' =3D N' XOR cipherState > C =3D C' > P' =3D D(Ke, C, IV') > using CBC-CS3-Decrypt defined > in [SP800-38A+] > if (PC > 0) > // IV =3D (N'[0:c - PC] | zeroblock[c - = PC:PC]) XOR > // (zeroblock[0:c - PC] | P'[c - = PC:PC]) > IV =3D (N'[0:c - PC] | P'[c - PC:PC]) > N =3D IV XOR cipherState > P =3D (P' XOR IV)[0:c - PC] > else > IV =3D IV' // but we no longer need = this > P =3D P' > N =3D N' > cipherState =3D N >=20 > The decrypt side is tricky to get right :) >=20 > Have at it. I'm sure I still slipped up. >=20 > Nico > -- From nico@cryptonector.com Wed May 29 10:50:03 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2703821F953E for ; Wed, 29 May 2013 10:50:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.077 X-Spam-Level: X-Spam-Status: No, score=-1.077 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zU0oH84nWYyI for ; Wed, 29 May 2013 10:49:57 -0700 (PDT) Received: from homiemail-a70.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id 71AF421F9539 for ; Wed, 29 May 2013 10:49:57 -0700 (PDT) Received: from homiemail-a70.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTP id 3A322768064 for ; Wed, 29 May 2013 10:49:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=VnnRidqmmPIZMUbyhEqH CLrx9QA=; b=Lyo4tfCBGHHGD0F40xU2+EbR80skzUMQ33DyXjJLXhEwlHHGWEu1 iPDTXtdolmtOSwYfmd+hg02HKZv36I8YwM3m2LD0rGIX1ZMRx9UIB3T5zhyeacML HY/94Lseo8wploWFt2aaB1r41ttThy6XebUzSF0ThoTDbC+Jw5XwIJc= Received: from mail-we0-f171.google.com (mail-we0-f171.google.com [74.125.82.171]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTPSA id D3A3A76805C for ; Wed, 29 May 2013 10:49:54 -0700 (PDT) Received: by mail-we0-f171.google.com with SMTP id t59so6715546wes.16 for ; Wed, 29 May 2013 10:49:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=cEXUGG6lnRqnVmTpqFZuHYo5HtkTxJsKNzclHmmc+MA=; b=dFXGvahpFEX17kA30X7O9ol0JhZOpUvQeosr7VKkxarGS8E95GKTuVTl6e2G8NWoU+ TkULN9rtSVPL+MpQpeAqo3igq32P2UPtezRA6OTFDD77KN4KBIp6uBNqb7o7bypQmnSs ezVOq4xoDKH6OPOGizF0jEFqXfptZiFV3P87kwtp87Hwwl1H9dAcs57P7apiCxE8IU/D 8fNpXlgf/FYPazmHe1P7uc5DYfeUe/4xZjYKpd/dFklbxgaSIOf7GLip+1KEAKwDOD9n TjE0hMsL01gcAnHSdJtw9TRLRiyZcQU10B2oeh99uGmh+nmnUEz5tjzRyfo80gnn+EkL D8fw== MIME-Version: 1.0 X-Received: by 10.180.90.70 with SMTP id bu6mr2055155wib.34.1369849790650; Wed, 29 May 2013 10:49:50 -0700 (PDT) Received: by 10.216.63.136 with HTTP; Wed, 29 May 2013 10:49:50 -0700 (PDT) In-Reply-To: References: <1AC28877-6470-4F3B-BCAC-A766D0322412@tycho.ncsc.mil> Date: Wed, 29 May 2013 12:49:50 -0500 Message-ID: From: Nico Williams To: Kelley Burgin Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org, Sam Hartman Subject: Re: [kitten] Random-IV and short-plaintexts (Re: Comments on draft-ietf-kitten-aes-cts-hmac-sha2-00) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 17:50:03 -0000 On Wed, May 29, 2013 at 12:35 PM, Kelley Burgin wrote: > I still have a question about the decrypt: seems like > > IV = (N'[0:c - PC] | P'[c - PC:PC]) is really N[0:c - PC] | IV[c - PC:PC]), not the original IV. Did I miss something? IV is not set at this point, so we can't refer to it in computing it. And IV' is the zeroblock in the case of short-plaintexts. > As you point out, we don't actually need to recover the IV (just N), so we can compute the plaintext P directly from P' by (if I didn't mess up): > > P = (P' XOR cipherState XOR N')[0:c - PC] We don't need to recover IV as a discrete element in this case. We do need to update cipherState, and there's simple re-writes of the above pseudo-code; I thought my verbose rendition should be preferable to something more concise, but maybe concise is better? From kwburgi@tycho.ncsc.mil Wed May 29 11:04:58 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F29C21F87E0 for ; Wed, 29 May 2013 11:04:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.249 X-Spam-Level: X-Spam-Status: No, score=-9.249 tagged_above=-999 required=5 tests=[AWL=0.750, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bZQt8ZViwaJQ for ; Wed, 29 May 2013 11:04:52 -0700 (PDT) Received: from nsa.gov (emvm-gh1-uea08.nsa.gov [63.239.67.9]) by ietfa.amsl.com (Postfix) with ESMTP id 70E5A21F9424 for ; Wed, 29 May 2013 11:04:49 -0700 (PDT) X-TM-IMSS-Message-ID: <74ada80b0010732b@nsa.gov> Received: from tarius.tycho.ncsc.mil ([144.51.31.2]) by nsa.gov ([63.239.67.9]) with ESMTP (TREND IMSS SMTP Service 7.1) id 74ada80b0010732b ; Wed, 29 May 2013 14:03:49 -0400 Received: from rd6um-58422h.infosec.tycho.ncsc.mil (rd6um-58422h [192.168.26.151]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id r4TI4gYc006961; Wed, 29 May 2013 14:04:42 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Kelley Burgin In-Reply-To: Date: Wed, 29 May 2013 14:08:49 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <3D72C077-FEA5-4B95-A93D-6B2B55A3DE95@tycho.ncsc.mil> References: <1AC28877-6470-4F3B-BCAC-A766D0322412@tycho.ncsc.mil> To: Nico Williams X-Mailer: Apple Mail (2.1084) Cc: kitten@ietf.org, Sam Hartman Subject: Re: [kitten] Random-IV and short-plaintexts (Re: Comments on draft-ietf-kitten-aes-cts-hmac-sha2-00) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 18:04:58 -0000 All this notation is confusing... I was meaning to say that when you decrypt C using the all zeros IV', = the value you get out is=20 P' =3D (P XOR N[0:c - PC] XOR cipherState[0:c - PC]) | (N[c - PC:PC] XOR = cipherState[c - PC:PC]) and=20 N' =3D N[0:c - PC] | C[c - PC:PC] where N is the nonce generated by the encryptor. So to define IV =3D N'[0:c - PC] | P'[c - PC:PC] will not define the = same IV the encryptor used. On May 29, 2013, at 1:49 PM, Nico Williams wrote: > On Wed, May 29, 2013 at 12:35 PM, Kelley Burgin = wrote: >> I still have a question about the decrypt: seems like >>=20 >> IV =3D (N'[0:c - PC] | P'[c - PC:PC]) is really N[0:c - PC] | IV[c - = PC:PC]), not the original IV. Did I miss something? >=20 > IV is not set at this point, so we can't refer to it in computing it. > And IV' is the zeroblock in the case of short-plaintexts. >=20 >> As you point out, we don't actually need to recover the IV (just N), = so we can compute the plaintext P directly from P' by (if I didn't mess = up): >>=20 >> P =3D (P' XOR cipherState XOR N')[0:c - PC] >=20 > We don't need to recover IV as a discrete element in this case. We do > need to update cipherState, and there's simple re-writes of the above > pseudo-code; I thought my verbose rendition should be preferable to > something more concise, but maybe concise is better? From nico@cryptonector.com Wed May 29 11:38:42 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76B1821F848E for ; Wed, 29 May 2013 11:38:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.777 X-Spam-Level: X-Spam-Status: No, score=-0.777 tagged_above=-999 required=5 tests=[AWL=1.200, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hIQQn4LaMllW for ; Wed, 29 May 2013 11:38:37 -0700 (PDT) Received: from homiemail-a24.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id 8CE2921F882A for ; Wed, 29 May 2013 11:38:32 -0700 (PDT) Received: from homiemail-a24.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTP id 2D6CB2C8094 for ; Wed, 29 May 2013 11:38:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=QXFXOPisiqR/lbGGs0Tz KD3SpxQ=; b=wCsUEYk736ovaUWaEZsT4FDyKbT0tS1J9MaPEyrEUJu8rqlbap1k oaJBSK47bJHuOeT2aYXYE3LXbpRpglJH9UzY9WD4k4Z8QI+j8XtBaglf2pApkQ89 U92xdNFoAI0m5ikD/LTvwjllNTsX62DzAvZYiXj63H9FIIDz1cMceD0= Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTPSA id D3B302C8383 for ; Wed, 29 May 2013 11:23:56 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id c10so3826366wiw.7 for ; Wed, 29 May 2013 11:23:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=E+vTPZpXjuQIx+yi4EqAn16TE+b7ggCAavcFGMPtnyY=; b=Tqb8XHcuECKoWJhhwUHNCgAVirilErsL/trfsBRHVVYBlxnrAdGZiYZLzY26MRueqx m7OxQTyQ+yLoKIaXVzhCPS+5jhEYPys2QMySc2T0VNuu1RUP/UYllW3mzoz9HOp5952g gN0ZqJdc/2M2d0Y/r+ri15wTcIjzJo2wVlN5cA3VKzdRfk9qk5ns04k6QR70zQ3jUpvp W1rwdMtYPCwPZObIRoU6xJjGvQYdOgdD+S53/QK0d6hFvtmr9m0GpI5/ygJjmK9CE2wV 1rBFX8Eb4EgL4B5OIAl0kf32Ifn6KATRkuZUMlBBcX8YjVXiJ/MVoVoVl0v3yL5L7pYc wNLQ== MIME-Version: 1.0 X-Received: by 10.180.90.70 with SMTP id bu6mr2094681wib.34.1369851835309; Wed, 29 May 2013 11:23:55 -0700 (PDT) Received: by 10.216.63.136 with HTTP; Wed, 29 May 2013 11:23:55 -0700 (PDT) Received: by 10.216.63.136 with HTTP; Wed, 29 May 2013 11:23:55 -0700 (PDT) In-Reply-To: <3D72C077-FEA5-4B95-A93D-6B2B55A3DE95@tycho.ncsc.mil> References: <1AC28877-6470-4F3B-BCAC-A766D0322412@tycho.ncsc.mil> <3D72C077-FEA5-4B95-A93D-6B2B55A3DE95@tycho.ncsc.mil> Date: Wed, 29 May 2013 13:23:55 -0500 Message-ID: From: Nico Williams To: Kelley Burgin Content-Type: multipart/alternative; boundary=f46d043be27a09e74e04dddf7c60 Cc: kitten@ietf.org, Sam Hartman Subject: Re: [kitten] Random-IV and short-plaintexts (Re: Comments on draft-ietf-kitten-aes-cts-hmac-sha2-00) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 18:38:42 -0000 --f46d043be27a09e74e04dddf7c60 Content-Type: text/plain; charset=UTF-8 On May 29, 2013 1:04 PM, "Kelley Burgin" wrote: > > All this notation is confusing... > > I was meaning to say that when you decrypt C using the all zeros IV', the value you get out is > > P' = (P XOR N[0:c - PC] XOR cipherState[0:c - PC]) | (N[c - PC:PC] XOR cipherState[c - PC:PC]) > > and > > N' = N[0:c - PC] | C[c - PC:PC] > > where N is the nonce generated by the encryptor. > > So to define IV = N'[0:c - PC] | P'[c - PC:PC] will not define the same IV the encryptor used. Right, but it's just XORed after the one block operation, so we can fix it with another XOR. I didn't want to use an E() with no IV, that's all :) --f46d043be27a09e74e04dddf7c60 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On May 29, 2013 1:04 PM, "Kelley Burgin" <kwburgi@tycho.ncsc.mil> wrote:
>
> All this notation is confusing...
>
> I was meaning to say that when you decrypt C using the all zeros IV= 9;, the value you get out is
>
> P' =3D (P XOR N[0:c - PC] XOR cipherState[0:c - PC]) | (N[c - PC:P= C] XOR cipherState[c - PC:PC])
>
> and
>
> N' =3D N[0:c - PC] | C[c - PC:PC]
>
> where N is the nonce generated by the encryptor.
>
> So to define IV =3D N'[0:c - PC] | P'[c - PC:PC] will not defi= ne the same IV the encryptor used.

Right, but it's just XORed after the one block operation= , so we can fix it with another XOR.=C2=A0 I didn't want to use an E() = with no IV, that's all :)

--f46d043be27a09e74e04dddf7c60-- From nico@cryptonector.com Wed May 29 12:29:43 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94BDC21F9790 for ; Wed, 29 May 2013 12:29:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.777 X-Spam-Level: X-Spam-Status: No, score=-0.777 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_12=0.6, J_CHICKENPOX_42=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J7NcfnlXU8t3 for ; Wed, 29 May 2013 12:29:38 -0700 (PDT) Received: from homiemail-a33.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id 96D2321F979E for ; Wed, 29 May 2013 12:29:31 -0700 (PDT) Received: from homiemail-a33.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTP id 10ECA594075 for ; Wed, 29 May 2013 12:29:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=xKeIjNnkkXqDE057cN3r ukUdWuQ=; b=mBs8zkzM3Li0KwKrwp0VcJElg+R4/3JhGrBwk+x1x6iIUwvEfqh6 xKhLxW8mRwGE7j0wM7hM5nZ/R8189PcSzrei2nXkKR0RduLHrGSWCdLcfjUeHgli +xbrdib0KPSHp1VN8MIjxrZiPBT2Kptd80OYSX+8Nf/oA6WHkuwbesU= Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTPSA id 83A5E594079 for ; Wed, 29 May 2013 12:29:03 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id c10so3883195wiw.13 for ; Wed, 29 May 2013 12:29:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=29St1TIqo1hSQJnXjU+I2HPBb50+6IFmFakIOB4YiBY=; b=CuOmnnZZxCWMQc6b3bfJuYxmceo6H0WIoW9dAgMBmtx67Dg52C4GpRJG1PbGeYthyt BzcmjpWtcyw0piAG2lz0UjHiS1hlKEotb3yaHyd2xv8amFH0dOOJT5115OZMs7okXUxq 63+JeoRYVGWrBUGVG968dRMhSFwQ4EnRxcBC4RmDoibKfOTjmM7YuRjlursSS9H9DcvA N+4yGHgeZUVBNNwre/zgGnj/VEEAew4wj4vWt50N2RR1IHbAWPgsDdFcY8ew/gep+THi gh1IOhX2onqjfFxzIdDGjiOOxycJpwDOW//rkLP2tbLNz9z8uLd1DKFUp9DbDUTGplOD es2g== MIME-Version: 1.0 X-Received: by 10.181.13.229 with SMTP id fb5mr2141394wid.16.1369855741800; Wed, 29 May 2013 12:29:01 -0700 (PDT) Received: by 10.216.63.136 with HTTP; Wed, 29 May 2013 12:29:01 -0700 (PDT) In-Reply-To: References: <1AC28877-6470-4F3B-BCAC-A766D0322412@tycho.ncsc.mil> <3D72C077-FEA5-4B95-A93D-6B2B55A3DE95@tycho.ncsc.mil> Date: Wed, 29 May 2013 14:29:01 -0500 Message-ID: From: Nico Williams To: Kelley Burgin Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org, Sam Hartman Subject: Re: [kitten] Random-IV and short-plaintexts (Re: Comments on draft-ietf-kitten-aes-cts-hmac-sha2-00) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 19:29:43 -0000 On Wed, May 29, 2013 at 1:23 PM, Nico Williams wrote: > Right, but it's just XORed after the one block operation, so we can fix it > with another XOR. I didn't want to use an E() with no IV, that's all :) Let me try to write clearer pseudo-code, but also more verbose :( And yes, there had been two bugs that I just noticed: 1) the encrypt side didn't quite handle non-short plaintexts, 2) I was missing an XOR of cipherState in the decrypt side. L(x) = length of x < = less-than operator; true == 1, false == 0 zeroblock = one block (length c) of zeros o[start:len] = sub-string operation returning the substring of length len of string o starting at byte start (zero-based) encryption function if (L(P) >= c) PC = 0 P' = P else PC = c - L(P) P' = P | zeroblock[0:PC] N = random nonce of length c (128 bits) IV = N XOR cipherState C = E(Ke, P', IV) // using CBC-CS3-Encrypt defined // in [SP800-38A+] if (PC > 0) N' = N[0:c - PC] | C[c - PC:PC] C' = C[0:c - PC] else N' = N C' = C H = HMAC(Ki, N' | C') ciphertext = N' | C' | H[1..h] cipherState = N decryption function (N', C', H) = ciphertext if (H != HMAC(Ki, N' | C')[1..h]) stop, report error if (L(C') >= c) // Not short-plaintext IV = N' XOR cipherState P = D(Ke, C', IV) // using CBC-CS3-Decrypt defined // in [SP800-38A+] cipherState = N' stop, output P, success // Short plaintext PC = c - L(C') C = C' | N[c - PC:PC] P' = D(Ke, C, zeroblock) // basically no IV // using CBC-CS3-Decrypt defined // in [SP800-38A+], but equivalent to ECB // with no IV; we have to fix up P' below // We need to compute the IV to recover P // with and cipherState // // N' had been N[0:c - PC] | C[c - PC:PC] and // we'd taken c-PC bytes from the original N to // make P'. First we reconstruct N: N = N'[0:c - PC] | P'[c - PC:PC] // Then use N to recover the IV (as above) IV = N XOR cipherState // XOR P' with the IV (because we used a zero IV // in D above, so we have to handle that here; // it's just one block, so this works), truncate // the result, and update the cipherState P = (P' XOR IV)[0:c - PC] cipherState = N stop, output P, success From nico@cryptonector.com Wed May 29 13:18:00 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F2D021F8ED8; Wed, 29 May 2013 13:17:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OcHpjbwq-BrO; Wed, 29 May 2013 13:17:53 -0700 (PDT) Received: from homiemail-a90.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id 9759B21F8E76; Wed, 29 May 2013 13:17:53 -0700 (PDT) Received: from homiemail-a90.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a90.g.dreamhost.com (Postfix) with ESMTP id A0DBF2AC0A9; Wed, 29 May 2013 13:17:51 -0700 (PDT) Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a90.g.dreamhost.com (Postfix) with ESMTPSA id D765C2AC0DB; Wed, 29 May 2013 13:16:22 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id hi5so3927927wib.6 for ; Wed, 29 May 2013 13:15:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=cH9Qd6mPXz5OIJvcUd+7TbHIE7iSSQKXFt8y1l+B1rU=; b=KvMMqLoi039XlY3zwkUoU11sbHV+W3OLlPXvhUNoMzCLPELABE9cY/j5MiBjqxx4DF uFidGQMtGVCZvK2m+Pg/Qmk/pTLY7U3067SweY+K8EUvfCNDQEvWz79lR5zs0YeYxN6M 9sPeCwswJygv1LjE1CQK5iJf80o9QRHxmlDpeGLVc+yYq9pgA1a3drKrrXzQUdT2Xu4g 9WJeWQJSECjJGKUmzttODmZer5fgwdUSY7Eq3/StYMRFh6w4vzOc0EE6SUYrb9xeGbfG NMxq4ijaShABg4Gy6zDa4xcfu69M5vvIyrEhRSJFqzwbfp5ly6hZ3dd+6X/hl8f3cZNg 5iRA== MIME-Version: 1.0 X-Received: by 10.194.83.5 with SMTP id m5mr2283589wjy.20.1369858532730; Wed, 29 May 2013 13:15:32 -0700 (PDT) Received: by 10.216.63.136 with HTTP; Wed, 29 May 2013 13:15:32 -0700 (PDT) In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE71296A3C67D@MX15A.corp.emc.com> References: <8D3D17ACE214DC429325B2B98F3AE71296A3C67D@MX15A.corp.emc.com> Date: Wed, 29 May 2013 15:15:32 -0500 Message-ID: From: Nico Williams To: "Black, David" Content-Type: text/plain; charset=UTF-8 Cc: "kitten@ietf.org" , "storm@ietf.org" Subject: Re: [kitten] Kerberos Considerations for iSCSI Authentication X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 20:18:00 -0000 On Wed, May 29, 2013 at 9:43 AM, Black, David wrote: > I do want to head off one area of comments - please send any "you > should use GSS-API" comments to /dev/null. iSCSI was specified to use > Kerberos w/o GSS-API a long time ago, so GSS-API for iSCSI would be a > new iSCSI authentication mechanism that should be in a separate draft, > as opposed to this update (which is already long enough). Other comments to head of: - Kebreros <-> IPsec binding? never mind; we failed to get uptake on RFC5660. > ------------------ > > 9.2.3 Kerberos Considerations for iSCSI Authentication > > iSCSI uses Kerberos via "bare" tokens - i.e. does not use GSS-API ([RFC4121]) - > for authenticating the two Kerberos principals during the iSCSI Login process. s/tokens/PDUs/ (and define the term: Protocol Data Unit). Or better: NEW: iSCSI uses raw Kerberos V5 [RFC4120] for authenticating a client (iSCSI initiator) principal to a service (iSCSI target) principal. Note that iSCSI does not use the Generic Security Services Application Programming Interface (GSS-API) [RFC2743] nor the Kerberos V5 GSS-API security mechanism [RFC4121]. > This implies that iSCSI implementations supporting the KRB5 AuthMethod > (Section 12.1) are directly involved in the Kerberos protocol. Specifically, > the following actions MUST be performed as specified in [RFC4120]: The first sentence of the above para says nothing to me :( Remove it? > - Target MUST validate the KRB_AP_REQ to ensure that the > initiator can be trusted > - When mutual authentication is selected, the initiator > MUST validate KRB_AP_REP > to determine the outcome of mutual authentication Yes. (Assuming there's text elsewhere saying that these PDUs have to be sent and received in order to validate them :) > As Kerberos V5 is capable of providing mutual authentication, implementations > SHOULD support mutual authentication by default for login authentication. Is there a reason not to make this a MUST? > Note however that Kerberos authentication only assures that the server > (iSCSI target) can be trusted by the Kerberos client (initiator) and > vice-versa; an initiator should employ appropriately secured service > discovery techniques (e.g. iSNS, Section 4.2.7) to ensure that it is > talking to the intended target principal. Some text somewhere should note that Kerberos is not used to provide integrity nor confidentiality protection to the iSCSI protocol (and that only IPsec does, and so on). Nico -- From nico@cryptonector.com Wed May 29 14:28:44 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCC4421F90AC for ; Wed, 29 May 2013 14:28:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.927 X-Spam-Level: X-Spam-Status: No, score=-0.927 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_12=0.6, J_CHICKENPOX_42=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S-LITMMPsOJQ for ; Wed, 29 May 2013 14:28:39 -0700 (PDT) Received: from homiemail-a33.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id C003721F8E12 for ; Wed, 29 May 2013 14:28:39 -0700 (PDT) Received: from homiemail-a33.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTP id 3D6ED5940C4 for ; Wed, 29 May 2013 14:28:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=lzCQKxpqJlIzXZBmO6JV PvxzKhw=; b=vJPQpNLNvMteStPA8NaYR0fMPgkR/7SeUCqUFo+oWwndwnD2/8jf IkDXG87cDGY89tqoFOBPiQyhwpmFY43C6Y9bWfgxoE3pXuAdQ01ZhKhWN431v7+f eC2p/KKzgMdmdiaUbtX7Fd5aAJKSz1yoK2Q0WTuWg1+otbS7nSJFH64= Received: from mail-ie0-f173.google.com (mail-ie0-f173.google.com [209.85.223.173]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTPSA id D6FE959442A for ; Wed, 29 May 2013 13:52:05 -0700 (PDT) Received: by mail-ie0-f173.google.com with SMTP id k13so6630847iea.32 for ; Wed, 29 May 2013 13:52:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LilCikNExRzth3moCJgF3a6dBJD69+u2i/Sr037M+9E=; b=NBkNTpPvYl5lxIsebmnOqx0vWnJPOQSmc+9t7C0+B69+oBsHj5sQIqvX5R+ad1cRLa CdeCKMuScHvR/Y2JWUbIQ3MDrkol+47sr74wnyTBhU2uLB3iDJalRZG2GnPFC2X0WcZl DWyBOG0IvOi6OWvMQ81Tb9dzN+2shSbzZ2XTnn5PNV//JngEhVKHr72ha+z2Jgcc8otN L6uYetXz3D2Wsy8t8jbFIZHNqPQ7KokYj2Iq1scZt6D9nUB2WFKZ7Lr3W5IE4LRC3HmM novBMJia04wGiDCLZpyrSimlbR5VnpGeOOVdokh65FJApWNZLNCoqJuZgzzCYFUlFiLH yf6Q== MIME-Version: 1.0 X-Received: by 10.50.106.114 with SMTP id gt18mr10215798igb.7.1369860724583; Wed, 29 May 2013 13:52:04 -0700 (PDT) Received: by 10.64.106.232 with HTTP; Wed, 29 May 2013 13:52:04 -0700 (PDT) In-Reply-To: References: <1AC28877-6470-4F3B-BCAC-A766D0322412@tycho.ncsc.mil> <3D72C077-FEA5-4B95-A93D-6B2B55A3DE95@tycho.ncsc.mil> Date: Wed, 29 May 2013 15:52:04 -0500 Message-ID: From: Nico Williams To: Kelley Burgin Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org, Sam Hartman Subject: Re: [kitten] Random-IV and short-plaintexts (Re: Comments on draft-ietf-kitten-aes-cts-hmac-sha2-00) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 21:28:44 -0000 Greg points out that for the short plaintext case I really have to clarify that E() and D() are ECB mode. L(x) = length of x < = less-than operator; true == 1, false == 0 zeroblock = one block (length c) of zeros o[start:len] = sub-string operation returning the substring of length len of string o starting at byte start (zero-based) encryption function N = random nonce of length c (128 bits) IV = N XOR cipherState if (L(P) > c) PC = 0 P' = P C = E(Ke, P', IV) // using CBC-CS3-Encrypt defined // in [SP800-38A+] N' = N C' = C else PC = c - L(P) P' = P | zeroblock[0:PC] C = E(Ke, P' XOR IV) // using ECB mode N' = N[0:c - PC] | C[c - PC:PC] C' = C[0:c - PC] H = HMAC(Ki, N' | C') ciphertext = N' | C' | H[1..h] cipherState = N decryption function (N', C', H) = ciphertext if (H != HMAC(Ki, N' | C')[1..h]) stop, report error if (L(C') >= c) // Not short-plaintext IV = N' XOR cipherState P = D(Ke, C', IV) // using CBC-CS3-Decrypt defined // in [SP800-38A+] cipherState = N' stop, output P, success // Short plaintext PC = c - L(C') C = C' | N[c - PC:PC] P' = D(Ke, C) // using ECB mode // We need to compute the IV to recover P // with and cipherState // // N' had been N[0:c - PC] | C[c - PC:PC] and // we'd taken c-PC bytes from the original N to // make P'. First we reconstruct N: N = N'[0:c - PC] | P'[c - PC:PC] // Then use N to recover the IV (as above) IV = N XOR cipherState // XOR P' with the IV (because we used a zero IV // in D above, so we have to handle that here; // it's just one block, so this works), truncate // the result, and update the cipherState P = (P' XOR IV)[0:c - PC] cipherState = N stop, output P, success From david.black@emc.com Wed May 29 17:18:59 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54C2A21F955C; Wed, 29 May 2013 17:18:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PBOjMeDLdagf; Wed, 29 May 2013 17:18:53 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 4862E21F949D; Wed, 29 May 2013 17:18:53 -0700 (PDT) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r4U0IhMx008012 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 May 2013 20:18:49 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd06.lss.emc.com [10.254.222.130]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Wed, 29 May 2013 20:18:34 -0400 Received: from mxhub21.corp.emc.com (mxhub21.corp.emc.com [128.222.70.133]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r4U0IX1V029834; Wed, 29 May 2013 20:18:34 -0400 Received: from mx15a.corp.emc.com ([169.254.1.184]) by mxhub21.corp.emc.com ([128.222.70.133]) with mapi; Wed, 29 May 2013 20:18:33 -0400 From: "Black, David" To: Nico Williams Date: Wed, 29 May 2013 20:18:33 -0400 Thread-Topic: [kitten] Kerberos Considerations for iSCSI Authentication Thread-Index: Ac5cqXI/5wO30C/LRfeOZY+V+aHxvgAIIP7Q Message-ID: <8D3D17ACE214DC429325B2B98F3AE71296A3C7C2@MX15A.corp.emc.com> References: <8D3D17ACE214DC429325B2B98F3AE71296A3C67D@MX15A.corp.emc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-EMM-MHVC: 1 X-Mailman-Approved-At: Wed, 29 May 2013 22:04:03 -0700 Cc: "kitten@ietf.org" , "storm@ietf.org" Subject: Re: [kitten] Kerberos Considerations for iSCSI Authentication X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 00:18:59 -0000 TmljbywNCg0KVGhhbmsgeW91IGZvciB0aGUgcHJvbXB0IGFuZCB1c2VmdWwgcmV2aWV3Lg0KDQpD b21tZW50cyBpbmxpbmUgLi4uDQoNClRoYW5rcywNCi0tRGF2aWQNCg0KPiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBOaWNvIFdpbGxpYW1zIFttYWlsdG86bmljb0BjcnlwdG9u ZWN0b3IuY29tXQ0KPiBTZW50OiBXZWRuZXNkYXksIE1heSAyOSwgMjAxMyA0OjE2IFBNDQo+IFRv OiBCbGFjaywgRGF2aWQNCj4gQ2M6IGtpdHRlbkBpZXRmLm9yZzsgc3Rvcm1AaWV0Zi5vcmcNCj4g U3ViamVjdDogUmU6IFtraXR0ZW5dIEtlcmJlcm9zIENvbnNpZGVyYXRpb25zIGZvciBpU0NTSSBB dXRoZW50aWNhdGlvbg0KPiANCj4gT24gV2VkLCBNYXkgMjksIDIwMTMgYXQgOTo0MyBBTSwgQmxh Y2ssIERhdmlkIDxkYXZpZC5ibGFja0BlbWMuY29tPiB3cm90ZToNCj4gPiBJIGRvIHdhbnQgdG8g aGVhZCBvZmYgb25lIGFyZWEgb2YgY29tbWVudHMgLSBwbGVhc2Ugc2VuZCBhbnkgInlvdQ0KPiA+ IHNob3VsZCB1c2UgR1NTLUFQSSIgY29tbWVudHMgdG8gL2Rldi9udWxsLiAgaVNDU0kgd2FzIHNw ZWNpZmllZCB0byB1c2UNCj4gPiBLZXJiZXJvcyB3L28gR1NTLUFQSSBhIGxvbmcgdGltZSBhZ28s IHNvIEdTUy1BUEkgZm9yIGlTQ1NJIHdvdWxkIGJlIGENCj4gPiBuZXcgaVNDU0kgYXV0aGVudGlj YXRpb24gbWVjaGFuaXNtIHRoYXQgc2hvdWxkIGJlIGluIGEgc2VwYXJhdGUgZHJhZnQsDQo+ID4g YXMgb3Bwb3NlZCB0byB0aGlzIHVwZGF0ZSAod2hpY2ggaXMgYWxyZWFkeSBsb25nIGVub3VnaCku DQo+IA0KPiBPdGhlciBjb21tZW50cyB0byBoZWFkIG9mZjoNCj4gDQo+ICAtIEtlcmJlcm9zIDwt PiBJUHNlYyBiaW5kaW5nPyAgbmV2ZXIgbWluZDsgd2UgZmFpbGVkIHRvIGdldCB1cHRha2Ugb24g UkZDNTY2MC4NCg0KSSdtIGFmcmFpZCBzbyAuLi4gc29ycnkuDQoNCj4gPiAtLS0tLS0tLS0tLS0t LS0tLS0NCj4gPg0KPiA+IDkuMi4zIEtlcmJlcm9zIENvbnNpZGVyYXRpb25zIGZvciBpU0NTSSBB dXRoZW50aWNhdGlvbg0KPiA+DQo+ID4gaVNDU0kgdXNlcyBLZXJiZXJvcyB2aWEgImJhcmUiIHRv a2VucyAtIGkuZS4gZG9lcyBub3QgdXNlIEdTUy1BUEkNCj4gKFtSRkM0MTIxXSkgLQ0KPiA+IGZv ciBhdXRoZW50aWNhdGluZyB0aGUgdHdvIEtlcmJlcm9zIHByaW5jaXBhbHMgZHVyaW5nIHRoZSBp U0NTSSBMb2dpbg0KPiBwcm9jZXNzLg0KPiANCj4gcy90b2tlbnMvUERVcy8gIChhbmQgZGVmaW5l IHRoZSB0ZXJtOiBQcm90b2NvbCBEYXRhIFVuaXQpLiAgT3IgYmV0dGVyOg0KPiANCj4gTkVXOg0K PiAgICBpU0NTSSB1c2VzIHJhdyBLZXJiZXJvcyBWNSBbUkZDNDEyMF0gZm9yIGF1dGhlbnRpY2F0 aW5nIGEgY2xpZW50DQo+IChpU0NTSSBpbml0aWF0b3IpIHByaW5jaXBhbCB0byBhIHNlcnZpY2Ug KGlTQ1NJIHRhcmdldCkgcHJpbmNpcGFsLg0KPiBOb3RlIHRoYXQgaVNDU0kgZG9lcyBub3QgdXNl IHRoZSBHZW5lcmljIFNlY3VyaXR5IFNlcnZpY2VzIEFwcGxpY2F0aW9uDQo+IFByb2dyYW1taW5n IEludGVyZmFjZSAoR1NTLUFQSSkgW1JGQzI3NDNdIG5vciB0aGUgS2VyYmVyb3MgVjUgR1NTLUFQ SQ0KPiBzZWN1cml0eSBtZWNoYW5pc20gW1JGQzQxMjFdLg0KDQorMSBvbiB0aGUgbmV3IHRleHQg LSB3ZSdsbCB0YWtlIGl0Lg0KIA0KPiA+IFRoaXMgaW1wbGllcyB0aGF0IGlTQ1NJIGltcGxlbWVu dGF0aW9ucyBzdXBwb3J0aW5nIHRoZSBLUkI1IEF1dGhNZXRob2QNCj4gPiAoU2VjdGlvbiAxMi4x KSBhcmUgZGlyZWN0bHkgaW52b2x2ZWQgaW4gdGhlIEtlcmJlcm9zIHByb3RvY29sLiBTcGVjaWZp Y2FsbHksDQo+ID4gdGhlIGZvbGxvd2luZyBhY3Rpb25zIE1VU1QgYmUgcGVyZm9ybWVkIGFzIHNw ZWNpZmllZCBpbiBbUkZDNDEyMF06DQo+IA0KPiBUaGUgZmlyc3Qgc2VudGVuY2Ugb2YgdGhlIGFi b3ZlIHBhcmEgc2F5cyBub3RoaW5nIHRvIG1lIDooICBSZW1vdmUgaXQ/DQo+IA0KDQpTdXJlLg0K DQo+ID4gICAgICAgICAgIC0gVGFyZ2V0IE1VU1QgdmFsaWRhdGUgdGhlIEtSQl9BUF9SRVEgdG8g ZW5zdXJlIHRoYXQgdGhlDQo+ID4gICAgICAgICAgICAgICAgICAgICAgICAgaW5pdGlhdG9yIGNh biBiZSB0cnVzdGVkDQo+ID4gICAgICAgICAgIC0gV2hlbiBtdXR1YWwgYXV0aGVudGljYXRpb24g aXMgc2VsZWN0ZWQsIHRoZSBpbml0aWF0b3INCj4gPiAgICAgICAgICAgICAgICAgICAgICAgICBN VVNUIHZhbGlkYXRlIEtSQl9BUF9SRVANCj4gPiAJCQkJCXRvIGRldGVybWluZSB0aGUgb3V0Y29t ZSBvZiBtdXR1YWwgYXV0aGVudGljYXRpb24NCj4gDQo+IFllcy4gIChBc3N1bWluZyB0aGVyZSdz IHRleHQgZWxzZXdoZXJlIHNheWluZyB0aGF0IHRoZXNlIFBEVXMgaGF2ZSB0bw0KPiBiZSBzZW50 IGFuZCByZWNlaXZlZCBpbiBvcmRlciB0byB2YWxpZGF0ZSB0aGVtIDopDQoNClllcywgdGhlcmUg aXMsIGFuZCB3ZSdsbCBkb3VibGUtY2hlY2suDQoNCj4gPiBBcyBLZXJiZXJvcyBWNSBpcyBjYXBh YmxlIG9mIHByb3ZpZGluZyBtdXR1YWwgYXV0aGVudGljYXRpb24sIGltcGxlbWVudGF0aW9ucw0K PiA+IFNIT1VMRCBzdXBwb3J0IG11dHVhbCBhdXRoZW50aWNhdGlvbiBieSBkZWZhdWx0IGZvciBs b2dpbiBhdXRoZW50aWNhdGlvbi4NCj4gDQo+IElzIHRoZXJlIGEgcmVhc29uIG5vdCB0byBtYWtl IHRoaXMgYSBNVVNUPw0KDQpZZXMsIGEgbG90IG9mIGRlcGxveWVkIGlTQ1NJIGF1dGhlbnRpY2F0 aW9uIGlzIG9uZS13YXkgLSBpbml0aWF0b3JzIChob3N0KQ0KYXV0aGVudGljYXRlIHRvIHRhcmdl dHMgKHN0b3JhZ2UpLCBidXQgbm90IHZpY2UtdmVyc2E7IGZvcmNpbmcgZGVmYXVsdHMNCnRvIG5l dmVyIG1hdGNoIGNvbW1vbiB1c2FnZSBoYXMgc29tZSBhbmFsb2dpZXMgdG8gdHJ5aW5nIHRvIHRl YWNoIGEgcGlnDQp0byBzaW5nIC4uLiBvbmUgZ2V0cyBubyBtdXNpYyBhbmQgb25seSBzdWNjZWVk cyBpbiBhbm5veWluZyB0aGUgcGlnIDotKS4NCg0KPiA+IE5vdGUgaG93ZXZlciB0aGF0IEtlcmJl cm9zIGF1dGhlbnRpY2F0aW9uIG9ubHkgYXNzdXJlcyB0aGF0IHRoZSBzZXJ2ZXINCj4gPiAoaVND U0kgdGFyZ2V0KSBjYW4gYmUgdHJ1c3RlZCBieSB0aGUgS2VyYmVyb3MgY2xpZW50IChpbml0aWF0 b3IpIGFuZA0KPiA+IHZpY2UtdmVyc2E7IGFuIGluaXRpYXRvciBzaG91bGQgZW1wbG95IGFwcHJv cHJpYXRlbHkgc2VjdXJlZCBzZXJ2aWNlDQo+ID4gZGlzY292ZXJ5IHRlY2huaXF1ZXMgKGUuZy4g aVNOUywgU2VjdGlvbiA0LjIuNykgdG8gZW5zdXJlIHRoYXQgaXQgaXMNCj4gPiB0YWxraW5nIHRv IHRoZSBpbnRlbmRlZCB0YXJnZXQgcHJpbmNpcGFsLg0KPiANCj4gU29tZSB0ZXh0IHNvbWV3aGVy ZSBzaG91bGQgbm90ZSB0aGF0IEtlcmJlcm9zIGlzIG5vdCB1c2VkIHRvIHByb3ZpZGUNCj4gaW50 ZWdyaXR5IG5vciBjb25maWRlbnRpYWxpdHkgcHJvdGVjdGlvbiB0byB0aGUgaVNDU0kgcHJvdG9j b2wgKGFuZA0KPiB0aGF0IG9ubHkgSVBzZWMgZG9lcywgYW5kIHNvIG9uKS4NCg0KU3VyZSwgZ29v ZCBzdWdnZXN0aW9uLCB3ZSdsbCBhZGQgYSBzZW50ZW5jZSB0byB0aGF0IGVmZmVjdC4NCg0KPiAN Cj4gTmljbw0KPiAtLQ0KDQo= From nico@cryptonector.com Thu May 30 12:57:32 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C09C21F8F9E for ; Thu, 30 May 2013 12:57:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.627 X-Spam-Level: X-Spam-Status: No, score=-0.627 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_12=0.6, J_CHICKENPOX_21=0.6, J_CHICKENPOX_42=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oCYoHsoWqh2b for ; Thu, 30 May 2013 12:57:27 -0700 (PDT) Received: from homiemail-a27.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id 6AD0D21F8F6D for ; Thu, 30 May 2013 12:57:27 -0700 (PDT) Received: from homiemail-a27.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTP id E20DF59805F for ; Thu, 30 May 2013 12:57:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=0ze6s5gm5rLr9zP6kmV4 QC6Jjsg=; b=R8+BBapY2ciKCxL4728hjSjxg+5YfbWuNHEAjx18pbbzpBFIgtDA Upq+IjTvNi9XKswJYts8Ca20B/7EUZPYKHI00A+TmT9dNhwiUvSRY7boRWOJPZu1 3Ts/a3lNTI1JRgRDmZBn5frINoCah2jIQWokkyDBPikxEvw0PlZhDoQ= Received: from mail-we0-f169.google.com (mail-we0-f169.google.com [74.125.82.169]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTPSA id B4A26598087 for ; Thu, 30 May 2013 12:57:13 -0700 (PDT) Received: by mail-we0-f169.google.com with SMTP id q55so620375wes.28 for ; Thu, 30 May 2013 12:57:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CeaArArC7D+m/j/8IjRiUj2Ye+JJZVwAbI+uUQwHt2Q=; b=PsC9z0Sg0h4GxMlLlqN46xvR50PVZkICHjDsGxvLnhd/ZoW0wZWdCe0gISzryems4y FH8u5w+AcfS9pEJnSaLPGskxnc8K8fnCNV2yC4XcalWLkEZKRwdKRsY2Wd9h8JxSsFpF fCUaPMmSrUirZoj08u6kfc2WX0nHzVhHcSx8y03taAFsLAVgT5qjAXMJQwCQ1HtgM94I h1c3qOy2/DFAwqNikEhAGBwUY1BW5qD3OTBkeItBlzghGFiCWLco5oxyDkc2w/h749v1 mbHFIpPUItJ8CZSEs3k6gYHHn9TQgmKMSGtUs9bwWZUC0Jt5HkeRJvOVQQfKbR+XYXx2 h32A== MIME-Version: 1.0 X-Received: by 10.180.87.33 with SMTP id u1mr288035wiz.34.1369943831926; Thu, 30 May 2013 12:57:11 -0700 (PDT) Received: by 10.216.63.136 with HTTP; Thu, 30 May 2013 12:57:11 -0700 (PDT) In-Reply-To: References: <1AC28877-6470-4F3B-BCAC-A766D0322412@tycho.ncsc.mil> <3D72C077-FEA5-4B95-A93D-6B2B55A3DE95@tycho.ncsc.mil> Date: Thu, 30 May 2013 14:57:11 -0500 Message-ID: From: Nico Williams To: Kelley Burgin Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org, Sam Hartman Subject: Re: [kitten] Random-IV and short-plaintexts (Re: Comments on draft-ietf-kitten-aes-cts-hmac-sha2-00) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 19:57:32 -0000 Kelly points out that the decrypt side I posted doesn't update cipherState properly and offers example inputs to work the code through. This should fix it (example below): decryption function (N', C', H) = ciphertext if (H != HMAC(Ki, N' | C')[1..h]) stop, report error if (L(C') >= c) // Not short-plaintext IV = N' XOR cipherState P = D(Ke, C', IV) // using CBC-CS3-Decrypt defined // in [SP800-38A+] cipherState = N' stop, output P, success // Short plaintext PC = c - L(C') C = C' | N[c - PC:PC] P' = D(Ke, C) // using ECB mode // P' here == (P | zeroblock[0:PC]) XOR IV // so IV[c - PC:PC] == P'[c - PC:PC] // In the non-short-pt case we'd recover // IV as N XOR cipherState, but here we only know // a head of N and tail of IV. N = N'[0:c -PC] | (P' XOR cipherState)[c - PC:PC] IV = N XOR cipherState P = (P' XOR IV)[0:PC] cipherState = N stop, output P, success Kelly proposes that we "suppose P = 1111, N = 10101010...., and cipherState = 010101010.... so that IV = 1111111.... (where the ... means the pattern repeats to fill out the block). Then the value encrypted is P+IV = 000011111111... which is the same value the decryptor ends up with as P'. N' is also defined to be 1010****** where the ***** is ciphertext". In Kelly's example PC = 12 (16 - 4). We need substring operations [0:4] and [4:12] So on the decrypt side N[0:4] == 1010, P'[0:4] = 0000, while P'[4:12] == 111111... == IV[4:12]. We have to recover either N[4:12] or IV[0:4], and then we can recover the other by XORing with cipherState. With the above pseudo code then we have: N = 1010 | (1111... XOR cipherState)[4:12] N = 1010 | 1111...[4:12] XOR 0101...[4:12] N = 10101010... IV = N XOR cipherState == 1111... P = (P' XOR IV)[0:4] == 11110000...[0:4] == 1111 So we recover the P correctly, and because we recover N correctly we then set cipherState correctly. Note that this: N = N'[0:PC] | (P' XOR cipherState)[c - PC:PC] IV = N XOR cipherState is equivalent to this: IV = (N' XOR cipherState)[0:PC] | P'[c - PC:PC] N = IV XOR cipherState If we plug data into that we get: IV = (1010****... XOR cipherState)[0:4] | P'[4:12] IV = 1010 XOR 0101 | 1111... IV = 1111 | 1111... == 1111.. N = 1111... XOR 0101... == 1010... and then P and cipherState come out the same as above. Nico -- From kwburgi@tycho.ncsc.mil Fri May 31 08:56:02 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6924E21F96EA for ; Fri, 31 May 2013 08:56:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.899 X-Spam-Level: X-Spam-Status: No, score=-8.899 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_21=0.6, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0M8n5pj9q58N for ; Fri, 31 May 2013 08:55:55 -0700 (PDT) Received: from nsa.gov (emvm-gh1-uea08.nsa.gov [63.239.67.9]) by ietfa.amsl.com (Postfix) with ESMTP id BB6E521F96EF for ; Fri, 31 May 2013 08:55:54 -0700 (PDT) X-TM-IMSS-Message-ID: <7e844bad00124eb8@nsa.gov> Received: from tarius.tycho.ncsc.mil ([144.51.31.2]) by nsa.gov ([63.239.67.9]) with ESMTP (TREND IMSS SMTP Service 7.1) id 7e844bad00124eb8 ; Fri, 31 May 2013 11:54:50 -0400 Received: from rd6um-58422h.infosec.tycho.ncsc.mil (rd6um-58422h [192.168.26.151]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id r4VFtmcB004011; Fri, 31 May 2013 11:55:48 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Kelley Burgin In-Reply-To: Date: Fri, 31 May 2013 11:59:59 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <084D4432-BB21-4A89-AA95-404A24949EB5@tycho.ncsc.mil> References: <1AC28877-6470-4F3B-BCAC-A766D0322412@tycho.ncsc.mil> <3D72C077-FEA5-4B95-A93D-6B2B55A3DE95@tycho.ncsc.mil> To: Nico Williams X-Mailer: Apple Mail (2.1084) Cc: kitten@ietf.org, Sam Hartman Subject: Re: [kitten] Random-IV and short-plaintexts (Re: Comments on draft-ietf-kitten-aes-cts-hmac-sha2-00) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2013 15:56:03 -0000 This looks great.=20 Last comment (I think): The encrypt side considers the case L(P) =3D c = to be short-plaintext, whereas the decrypt side considers it not short = ("L(P) > c" vs "L(C') >=3D c").=20 Also, guess C =3D C' | N[c - PC:PC] in the short-plaintext decrypt = should use N'. Kelley On May 30, 2013, at 3:57 PM, Nico Williams wrote: > Kelly points out that the decrypt side I posted doesn't update > cipherState properly and offers example inputs to work the code > through. This should fix it (example below): >=20 > decryption function > (N', C', H) =3D ciphertext > if (H !=3D HMAC(Ki, N' | C')[1..h]) > stop, report error >=20 > if (L(C') >=3D c) > // Not short-plaintext > IV =3D N' XOR cipherState > P =3D D(Ke, C', IV) > // using CBC-CS3-Decrypt defined > // in [SP800-38A+] > cipherState =3D N' > stop, output P, success >=20 > // Short plaintext > PC =3D c - L(C') > C =3D C' | N[c - PC:PC] > P' =3D D(Ke, C) > // using ECB mode >=20 > // P' here =3D=3D (P | zeroblock[0:PC]) XOR IV > // so IV[c - PC:PC] =3D=3D P'[c - PC:PC] > // In the non-short-pt case we'd recover > // IV as N XOR cipherState, but here we only know > // a head of N and tail of IV. >=20 > N =3D N'[0:c -PC] | (P' XOR cipherState)[c - = PC:PC] > IV =3D N XOR cipherState >=20 >=20 > P =3D (P' XOR IV)[0:PC] > cipherState =3D N > stop, output P, success >=20 > Kelly proposes that we "suppose P =3D 1111, N =3D 10101010...., and > cipherState =3D 010101010.... so that IV =3D 1111111.... (where the = ... > means the pattern repeats to fill out the block). Then the value > encrypted is P+IV =3D 000011111111... which is the same value the > decryptor ends up with as P'. N' is also defined to be 1010****** > where the ***** is ciphertext". >=20 > In Kelly's example PC =3D 12 (16 - 4). We need substring operations > [0:4] and [4:12] >=20 > So on the decrypt side N[0:4] =3D=3D 1010, P'[0:4] =3D 0000, while = P'[4:12] > =3D=3D 111111... =3D=3D IV[4:12]. We have to recover either N[4:12] = or > IV[0:4], and then we can recover the other by XORing with cipherState. > With the above pseudo code then we have: >=20 > N =3D 1010 | (1111... XOR cipherState)[4:12] > N =3D 1010 | 1111...[4:12] XOR 0101...[4:12] > N =3D 10101010... > IV =3D N XOR cipherState =3D=3D 1111... > P =3D (P' XOR IV)[0:4] =3D=3D 11110000...[0:4] =3D=3D 1111 >=20 > So we recover the P correctly, and because we recover N correctly we > then set cipherState correctly. >=20 > Note that this: >=20 > N =3D N'[0:PC] | (P' XOR cipherState)[c - PC:PC] > IV =3D N XOR cipherState >=20 > is equivalent to this: >=20 > IV =3D (N' XOR cipherState)[0:PC] | P'[c - PC:PC] > N =3D IV XOR cipherState >=20 > If we plug data into that we get: >=20 > IV =3D (1010****... XOR cipherState)[0:4] | P'[4:12] > IV =3D 1010 XOR 0101 | 1111... > IV =3D 1111 | 1111... =3D=3D 1111.. > N =3D 1111... XOR 0101... =3D=3D 1010... >=20 > and then P and cipherState come out the same as above. >=20 > Nico > -- From kwburgi@tycho.ncsc.mil Fri May 31 13:31:14 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45E5E21F8EB1 for ; Fri, 31 May 2013 13:31:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.11 X-Spam-Level: X-Spam-Status: No, score=-9.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kA5yT+b+A+Qu for ; Fri, 31 May 2013 13:31:08 -0700 (PDT) Received: from nsa.gov (emvm-gh1-uea08.nsa.gov [63.239.67.9]) by ietfa.amsl.com (Postfix) with ESMTP id 13DAC21F89EB for ; Fri, 31 May 2013 13:31:04 -0700 (PDT) X-TM-IMSS-Message-ID: <7f803e7900128f2f@nsa.gov> Received: from tarius.tycho.ncsc.mil ([144.51.31.2]) by nsa.gov ([63.239.67.9]) with ESMTP (TREND IMSS SMTP Service 7.1) id 7f803e7900128f2f ; Fri, 31 May 2013 16:30:02 -0400 Received: from rd6um-58422h.infosec.tycho.ncsc.mil (rd6um-58422h [192.168.26.151]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id r4VKV0oM024873 for ; Fri, 31 May 2013 16:31:00 -0400 From: Kelley Burgin Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 31 May 2013 16:35:13 -0400 Message-Id: <0B56359E-4D42-4CEB-A8EF-1E5AB2A333ED@tycho.ncsc.mil> To: kitten@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [kitten] Collected comments on draft-ietf-kitten-aes-cts-hmac-sha2 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2013 20:31:14 -0000 I've tried to collect all the comments on = draft-ietf-kitten-aes-cts-hmac-sha2 in one place (most just copied and = pasted from earlier mail). If you've made one I missed, or have one to = make, please let me know. I'm still not sure that there's a plan for 3) = below. 1) Make no reference to terminology or concepts introduced in the = simplified profile in RFC 3961. Refer only to RFC 3961 sections 3 and 4. = Further detailed comments by Sam to be addressed on this. 2) Minimize references to RFC 3962; in general repeating text from RFC = 3962 is probably better than references. Further detailed comments by = Sam to be addressed on this. 3) New section on random in salts and the issues they raise?=20 4) Include some text in Section 1 that points out there is no = confounding along with reasons for this design choice.=20 5) Add a solution to the short plaintext problem=20 6) Use cipherState throughout, and just say XOR (instead of + with = explanation)= From cantor.2@osu.edu Fri May 31 13:43:29 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3551821F8556 for ; Fri, 31 May 2013 13:43:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.74 X-Spam-Level: X-Spam-Status: No, score=-1.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XpOXDx69LbxQ for ; Fri, 31 May 2013 13:43:23 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe005.messaging.microsoft.com [216.32.180.31]) by ietfa.amsl.com (Postfix) with ESMTP id 5EC6921F852D for ; Fri, 31 May 2013 13:43:18 -0700 (PDT) Received: from mail8-va3-R.bigfish.com (10.7.14.242) by VA3EHSOBE004.bigfish.com (10.7.40.24) with Microsoft SMTP Server id 14.1.225.23; Fri, 31 May 2013 20:43:17 +0000 Received: from mail8-va3 (localhost [127.0.0.1]) by mail8-va3-R.bigfish.com (Postfix) with ESMTP id 50EDC260162; Fri, 31 May 2013 20:43:17 +0000 (UTC) X-Forefront-Antispam-Report: CIP:164.107.81.212; KIP:(null); UIP:(null); IPV:NLI; H:cio-krc-pf05; RD:none; EFVD:NLI X-SpamScore: 6 X-BigFish: VPS6(zz1432Izz1f42h1d77h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzzz2fh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1b1cn1b1bi1155h) Received-SPF: pass (mail8-va3: domain of osu.edu designates 164.107.81.212 as permitted sender) client-ip=164.107.81.212; envelope-from=cantor.2@osu.edu; helo=cio-krc-pf05 ; cio-krc-pf05 ; Received: from mail8-va3 (localhost.localdomain [127.0.0.1]) by mail8-va3 (MessageSwitch) id 137003299513098_23084; Fri, 31 May 2013 20:43:15 +0000 (UTC) Received: from VA3EHSMHS016.bigfish.com (unknown [10.7.14.238]) by mail8-va3.bigfish.com (Postfix) with ESMTP id F363C1400D7; Fri, 31 May 2013 20:43:14 +0000 (UTC) Received: from cio-krc-pf05 (164.107.81.212) by VA3EHSMHS016.bigfish.com (10.7.99.26) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 31 May 2013 20:43:14 +0000 Received: from CIO-TNC-HT05.osuad.osu.edu (localhost [127.0.0.1]) by cio-krc-pf05 (Postfix) with ESMTP id 4762D60049; Fri, 31 May 2013 16:43:14 -0400 (EDT) Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-TNC-HT05.osuad.osu.edu ([fe80::d0be:603:484c:5a2f%10]) with mapi id 14.02.0328.009; Fri, 31 May 2013 16:43:14 -0400 From: "Cantor, Scott" To: Shawn Emery , "kitten@ietf.org" Thread-Topic: [kitten] Consensus Calls Thread-Index: AQHOUT3aIrF3bdlgfUSMsMD4ENJW6Jkf255w Date: Fri, 31 May 2013 20:43:13 +0000 Message-ID: References: <51927692.1090007@oracle.com> <519338F5.3030006@oracle.com> In-Reply-To: <519338F5.3030006@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [164.107.161.117] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forward X-OriginatorOrg: osu.edu Subject: Re: [kitten] Consensus Calls X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2013 20:43:29 -0000 Couple days late, sorry. > 1. In regards to draft-ietf-kitten-sasl-oauth, RFC 6616, and RFC 6595; do= we > allow for GS2 mechanisms that don't provide mutual authentication? This > would entail changing the GS2 specification (RFC 5801) to relax this > constraint. >=20 > a. Yes > b. No > c. Don't care or need more information I'm going with (c) specifically in that I'd want to understand the implicat= ions for existing libraries/code that would have to change. I put a high pr= emium on avoiding platform lifts. Red Hat 5 and whatever it shipped with wi= ll be supported but frozen through 2017, to use one egregious example. -- Scott From nico@cryptonector.com Fri May 31 13:45:38 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A3A721F859A for ; Fri, 31 May 2013 13:45:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.477 X-Spam-Level: X-Spam-Status: No, score=-1.477 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wBCL4yO-R4Yq for ; Fri, 31 May 2013 13:45:33 -0700 (PDT) Received: from homiemail-a70.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id 3696B21F852D for ; Fri, 31 May 2013 13:45:33 -0700 (PDT) Received: from homiemail-a70.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTP id 1748576806D for ; Fri, 31 May 2013 13:45:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=hsBehWgvaclRewJi9t7p DzwKsEw=; b=UTEiAuhEKj4QjCory+PccrRRLpoLaPUKSBd2D2hF07R6H2uWqQq5 /U5VgeNfwdQUIqOJFiNtHn/8u8XMVyyPPLcl6VQblS9s5pER2hzbpwR7z+tj7/Cv JWZ9Ss0oA43W2pAy4zEYdszGZXNFymVPJapx+tdoqQjIQgOrc3rDGjk= Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTPSA id D144D768064 for ; Fri, 31 May 2013 13:45:30 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id c10so1057932wiw.3 for ; Fri, 31 May 2013 13:45:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=j5BG0cem48siWuT4NImjO4qLD8NSPnduZf+y56dznTs=; b=JOpd9nWCyQPfoabS6wQCsbSzD0ITJOo/LIpMdpA478UP/klK0/qqPW35YMJKUMXe6q t+D6H1yL4qNOCg76SoPX5kbbVYa+qb6uS50ACLbe3NUcRkYeHEJyGaE2B1PUNqSuHofG raynsl5+1ji0xZKBFs+BRn8GQhVOa3H4AsX1Iv4uMibnrjxcJY5N5SgfJzqAMUk8QCC5 9SA5ye2eCAi/j+AZzjS76VQwGFyZWn0Zl2c8aePDjxGp6BhFpFMJNFFAn+ZgzPtAPlbb qdXhwUVI5WTRX9EiJoK5T6aKo63BdpDE5rcXH5izrUVlBWlXoVNY26LxD0RPsb7O30TN 0+hQ== MIME-Version: 1.0 X-Received: by 10.194.83.5 with SMTP id m5mr11052070wjy.20.1370033127968; Fri, 31 May 2013 13:45:27 -0700 (PDT) Received: by 10.216.63.136 with HTTP; Fri, 31 May 2013 13:45:27 -0700 (PDT) In-Reply-To: <084D4432-BB21-4A89-AA95-404A24949EB5@tycho.ncsc.mil> References: <1AC28877-6470-4F3B-BCAC-A766D0322412@tycho.ncsc.mil> <3D72C077-FEA5-4B95-A93D-6B2B55A3DE95@tycho.ncsc.mil> <084D4432-BB21-4A89-AA95-404A24949EB5@tycho.ncsc.mil> Date: Fri, 31 May 2013 15:45:27 -0500 Message-ID: From: Nico Williams To: Kelley Burgin Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org, Sam Hartman Subject: Re: [kitten] Random-IV and short-plaintexts (Re: Comments on draft-ietf-kitten-aes-cts-hmac-sha2-00) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2013 20:45:38 -0000 On Fri, May 31, 2013 at 10:59 AM, Kelley Burgin wrote: > This looks great. Awesome. > Last comment (I think): The encrypt side considers the case L(P) = c to be short-plaintext, whereas the decrypt side considers it not short ("L(P) > c" vs "L(C') >= c"). Let's call that a typo :) It should be > in both cases. > Also, guess C = C' | N[c - PC:PC] in the short-plaintext decrypt should use N'. Also a typo. Nico --