Polk, William T. | 1 Nov 16:11 2010

Public Review: NIST draft publication on extraction-then-expansion key derivation

Folks,

I apparently black-holed an important NIST email last September.  NIST has
published a draft specification covering key derivation functions based on
the extraction-then-expansion model we standardized in RFC 5869.
Unfortunately, I failed to forward the request for feedback on the draft to
this list.  

The official comment period closed October 30, but the authors were hoping
for more feedback from IETF participants, and have asked me (a second time)
to send the call to the community.  The authors have assured me that
comments submitted before November 30 will be received in plenty of time for
the revision process.

Thanks,

Tim Polk

> Call for Comments:
>  
> This is a reminder that the comment period for draft SP 800-56C,
> Recommendation for Key Derivation through Extraction-then-Expansion will close
> on October 30, 2010.  The announcement and draft can be found at
> http://csrc.nist.gov/publications/PubsDrafts.html#SP-800-56-C
>  
> Please submit comments to 800-56Ccomments <at> nist.gov with "Comments on SP
> 800-56C" in the subject line.

Hugo Krawczyk | 1 Nov 17:07 2010
Picon

Re: Public Review: NIST draft publication on extraction-then-expansion key derivation

Hi Tim,

I included the following point in comments I submitted to NIST, yet it may be worth repeating it here. SP 800-56C SEEMS to allow for the use of the technique standardized in RFC 5869. However, to arrive to that conclusion one has to carefully parse SP 800-56C as well as 800-108 and navigate the optional parts of these schemes. To avoid confusion and many questions in the future, I recommend that SP 800-56C (and preferably also the recent draft SP 800-135) EXPLICITLY mention the specific HKDF scheme from RFC 5869 as an instance allowed by these NIST documents.

Thanks,

Hugo

On Mon, Nov 1, 2010 at 11:11 AM, Polk, William T. <william.polk <at> nist.gov> wrote:
Folks,

I apparently black-holed an important NIST email last September.  NIST has
published a draft specification covering key derivation functions based on
the extraction-then-expansion model we standardized in RFC 5869.
Unfortunately, I failed to forward the request for feedback on the draft to
this list.

The official comment period closed October 30, but the authors were hoping
for more feedback from IETF participants, and have asked me (a second time)
to send the call to the community.  The authors have assured me that
comments submitted before November 30 will be received in plenty of time for
the revision process.

Thanks,

Tim Polk


> Call for Comments:
>
> This is a reminder that the comment period for draft SP 800-56C,
> Recommendation for Key Derivation through Extraction-then-Expansion will close
> on October 30, 2010.  The announcement and draft can be found at
> http://csrc.nist.gov/publications/PubsDrafts.html#SP-800-56-C
>
> Please submit comments to 800-56Ccomments <at> nist.gov with "Comments on SP
> 800-56C" in the subject line.

_______________________________________________
saag mailing list
saag <at> ietf.org
https://www.ietf.org/mailman/listinfo/saag

<div>
<p>Hi Tim,<br><br>I included the following point in comments I submitted to NIST, yet it may be worth repeating it here. SP 800-56C SEEMS to allow for the use of the technique standardized in RFC 5869. However, to arrive to that conclusion one has to carefully parse SP 800-56C as well as 800-108 and navigate the optional parts of these schemes. To avoid confusion and many questions in the future, I recommend that SP 800-56C (and preferably also the recent draft SP 800-135) EXPLICITLY mention the specific HKDF scheme from RFC 5869 as an instance allowed by these NIST documents.<br><br>Thanks,<br><br>Hugo<br><br></p>
<div class="gmail_quote">On Mon, Nov 1, 2010 at 11:11 AM, Polk, William T. <span dir="ltr">&lt;<a href="mailto:william.polk <at> nist.gov">william.polk <at> nist.gov</a>&gt;</span> wrote:<br><blockquote class="gmail_quote">

Folks,<br><br>
I apparently black-holed an important NIST email last September. &nbsp;NIST has<br>
published a draft specification covering key derivation functions based on<br>
the extraction-then-expansion model we standardized in RFC 5869.<br>
Unfortunately, I failed to forward the request for feedback on the draft to<br>
this list.<br><br>
The official comment period closed October 30, but the authors were hoping<br>
for more feedback from IETF participants, and have asked me (a second time)<br>
to send the call to the community. &nbsp;The authors have assured me that<br>
comments submitted before November 30 will be received in plenty of time for<br>
the revision process.<br><br>
Thanks,<br><br>
Tim Polk<br><br><br>
&gt; Call for Comments:<br>
&gt;<br>
&gt; This is a reminder that the comment period for draft SP 800-56C,<br>
&gt; Recommendation for Key Derivation through Extraction-then-Expansion will close<br>
&gt; on October 30, 2010. &nbsp;The announcement and draft can be found at<br>
&gt; <a href="http://csrc.nist.gov/publications/PubsDrafts.html#SP-800-56-C" target="_blank">http://csrc.nist.gov/publications/PubsDrafts.html#SP-800-56-C</a><br>
&gt;<br>
&gt; Please submit comments to <a href="mailto:800-56Ccomments <at> nist.gov">800-56Ccomments <at> nist.gov</a> with "Comments on SP<br>
&gt; 800-56C" in the subject line.<br><br>
_______________________________________________<br>
saag mailing list<br><a href="mailto:saag <at> ietf.org">saag <at> ietf.org</a><br><a href="https://www.ietf.org/mailman/listinfo/saag" target="_blank">https://www.ietf.org/mailman/listinfo/saag</a><br>
</blockquote>
</div>
<br>
</div>
Henry B. Hotz | 8 Nov 22:22 2010
Picon
Picon

Re: New Version Notification for draft-hotz-kx509-01

I think I've incorporated all the suggested changes, except the ones that would create a new incompatible protocol.

I intend to start discussion of a new version to fix the warts, but let's take care of this baseline first.

On Nov 8, 2010, at 12:01 PM, IETF I-D Submission Tool wrote:

> 
> A new version of I-D, draft-hotz-kx509-01.txt has been successfully submitted by Henry Hotz and posted
to the IETF repository.
> 
> Filename:	 draft-hotz-kx509
> Revision:	 01
> Title:		 KX509 Kerberized Certificate Issuance Protocol
> Creation_date:	 2010-11-08
> WG ID:		 Independent Submission
> Number_of_pages: 10
> 
> Abstract:
> This rfc describes a protocol, called kx509, for using Kerberos
> tickets to acquire X.509 certificates.
> 
> While not (previously) standardized, this protocol is already in use
> at several large organizations, and certificates issued with this
> protocol are recognized by TAGPMA (The Americas Grid Policy
> Management Authority).
> 
> 
> 
> The IETF Secretariat.

------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz <at> jpl.nasa.gov, or hbhotz <at> oxy.edu

_______________________________________________
ietf-krb-wg mailing list
ietf-krb-wg <at> lists.anl.gov
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

Shawn M Emery | 9 Nov 08:39 2010
Picon

Kitten Working Group Summary - IETF 79


The kitten WG met Tuesday, 11/9/10, during the first morning session for
two hours.

Co-chairs: Shawn Emery, Tom Yu

The goals of the meeting were to review the state of the active WG
items, discuss implementing kitten technologies, SASL-SAML vs
SASL-SAML-EC, and the SASL-OAuth draft.

gssapi-extensions-iana
----------------------------
Consensus on the list was to standardize a per programming language
register.
Co-chairs will ask the editor again to update the draft with per
programming language registry text.

draft-ietf-kitten-digest-to-historic
----------------------------------------
Tom Yu has agreed to perform the PROTO write-up for this draft.

gssapi-naming-exts
------------------------
Current state is: Revised ID needed.

Sam Hartman has volunteered to provide text to resolve issues that he
has presented at the last IETF meeting. He has also agreed to create a
separate SAML mechanism implementation draft for naming extensions.

draft-ietf-kitten-sasl-openid
---------------------------------
Still looking for review and comments.

draft-ietf-kitten-sasl-saml
-------------------------------
New version submitted to clarify security considerations section to
include a secure channel for the mechanism. The draft was updated to
use a URI redirect instead of an HTTP.

Looking for review and comments.

Presentations
----------------
Implementation Feed-back of Kitten Technologies by Sam Hartman

Sam discussed some positive feed-back in implementing a GSS-API
mechanism besides Kerberos, GSS-EAP. There were some limitations and
some complimentary libraries required to perform mappings, for example.

SASL-SAML and SASL-SAML-EC by Klaas Wierenga

There was confusion on the list between the differences between
SASL-SAML and SASL-SAML-EC mechanisms. Klaas discussed the
infrastructure and protocol differences between the two mechanisms.

SASL-OAuth by Hannes Tschofenig

There will be a consensus call on the list to decide whether to adopt
the SASL-SAML-EC and SASL-OAuth drafts in the WG and to discuss how to
address the security issues associated with these and the SASL OpenID
and SAML drafts currently in the WG charter.

Charter Discussion
-----------------------
Still looking for volunteers for the following work items
initialization/new credentials
listing/iterating credentials
exporting/importing credentials
error message reporting
asynchronous calls
security strength reporting
programmer friendliness

There has been greater interest in initial credentials and asynchronous
calls. The WG should pursue these fairly soon.

Shawn kitten co-chair
--
Barry Leiba | 9 Nov 09:01 2010
Picon

DKIM working group summary for IETF 79

DKIM is not meeting at IETF 79.

We are working on finishing up 4871bis (taking DKIM base to Draft
Standard), aiming to get it to the IESG in December -- the
interoperability report is done and ready.

Following that, we will finish up the "mailing lists" informational
document, aiming to get that to the IESG by February.

We will then evaluate the energy and likelihood of progress on other
items, and consider the future of the working group.

Barry (and Stephen), DKIM chair(s)
Stephen Kent | 10 Nov 08:00 2010
Picon

PKIX report

PKIX met for about an hour, on Wednesday morning, with about out 30 attendees.

A quick doc status review:
	- 3 new RFCs: 5934, 6024, & 6025
	- 2 in IESG (1 about to begin IETF LC)
	- 4 in the WG: CMC Updates, 5280 clarifications, OCSP update
	    and transport protocols for CMP

The OCSP update doc is essentially done, and we elected to defer a 
couple of issues until we begin work on OCSP-bis.

We decided to issue a new doc defining SMIME Capabilities for signature
alg parameters, to address an OCSP alg agility requirement.

We also had a presentation on an I-D from the SIDR WG, which 
describes another approach to local management of trust anchors. The 
mechanism described
here is somewhat complex, because of the need to accommodate the path 
validation rules of RFC 3779. (The Resoure PKI, developed in the SIDR 
WG, makes use of 3779 extensions, and thus the complexity is needed 
in that context).  However, the basic notion of re-issuing proffered 
TAs under an RP-controlled TA, may of general utility.
Tobias Gondrom | 10 Nov 10:05 2010

LTANS report

LTANS did not meet in Beijing.

ltans status:
WG in final phase and should be closed very soon.
One last document draft-ietf-ltans-xmlers-07.txt received some late
(after close of WGLC) comments, which are currently answered by the
authors. Draft will go to IESG afterwards.

Two other drafts: ari and validate will (as agreed in Maastricht) be
proceeded outside of WG as individual and indepedent submissions.

Tobias

Steve Hanna | 10 Nov 10:40 2010
Picon

SCAP BOF Report

The SCAP BOF met on Tuesday, November 9 from 1520 to 1810. This was
an exploratory BOF devoted to exploring the possible ways in which the
IETF and SCAP communities can work together. After an SCAP Overview
and several presentations that looked at SCAP from several perspectives
(Network Management, NEA, and ITU CYBEX), there was an extensive Q&A
and a discussion of the possibilities for collaboration. The group
agreed to write
up an Internet Draft with collaboration ideas, focusing especially on network
protocols that the SCAP community needs: reporting on SCAP compliance
within a NEA assessment, provisioning XCCDF and OVAL content to an
endpoint, etc. This draft can stimulate more concrete discussions about
whether a WG should be formed.
Yaron Sheffer | 10 Nov 11:39 2010
Picon

ipsecme meeting report

IPsecME met Wednesday afternoon. We reviewed document status: IKEv2-bis 
was published (RFC 5996), as well as Mutual EAP Authentication (RFC 
5998) and the High Availability Problem Statement (RFC 6207). IPsec 
Roadmap is an in RFC Editor queue.

There was a long discussion of the failure detection draft, where the 
focus was on exactly which deployment scenarios we want this mechanism 
to support.

A new revision of the HA protocol was presented. It resolves the main 
issues that were raised in Maastricht, but still has a few open issues 
that we should aim to close within the next few weeks.

It is our goal to have both these draft through WGLC before Prague.

Three other non-WG items were discussed:
- A stripped down version of the IKEv2 document - somewhere between a 
tutorial and a minimal profile.
- An implementation of IKEv2 authentication using IPv6 CGAs.
- A draft on optimized IKEv2 reauthetication, where you don't have to 
restart the whole IKE SA plus its dependent IPsec SAs.
Steve Hanna | 10 Nov 15:05 2010
Picon

NEA report

The NEA WG met on Monday, November 8 from 1300 to 1500. We heard a report
from the NEA Asokan Attack Mitigation Design Team that we started up after the
last IETF meeting. They recommended using the tls-unique channel bindings to
address the NEA Asokan attack by binding the Posture Transport protocol (PT)
to a PA protocol message exchange with an External Measurement Agent (EMA),
as described in draft-salowey-nea-asokan-00.txt. There was complete consensus
in the room to take this approach. Assuming this consensus is confirmed on the
email list, the next step is to update the PT proposals to reflect it
and to create
an informational document with guidance for EMA implementors. We plan to hold
a virtual interim meeting in January to decide which PT proposals will
go forward.
By IETF 80, we should have WG drafts for PT and we hope to complete work on
those by August 2011.

Gmane