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

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.
Permalink | Reply | 1 comment |
headers
Hugo Krawczyk | 1 Nov 2010 17:07
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>
Permalink | Reply | 0 comments |
headers
Shawn M Emery | 9 Nov 2010 08:39
Picon
Favicon

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
--
Permalink | Reply | 0 comments |
headers
Barry Leiba | 9 Nov 2010 09:01
Picon
Favicon
Gravatar

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)
Permalink | Reply | 0 comments |
headers
Stephen Kent | 10 Nov 2010 08:00
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.
Permalink | Reply | 0 comments |
headers
Tobias Gondrom | 10 Nov 2010 10:05
Favicon

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
Permalink | Reply | 0 comments |
headers
Steve Hanna | 10 Nov 2010 10:40
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.
Permalink | Reply | 0 comments |
headers
Yaron Sheffer | 10 Nov 2010 11:39
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.
Permalink | Reply | 0 comments |
headers
Steve Hanna | 10 Nov 2010 15:05
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.
Permalink | Reply | 0 comments |
headers
Juergen Schoenwaelder | 10 Nov 2010 16:35
Picon
Favicon

ISMS report

The ISMS working group met in a one hour session on Wednesday at 15:10
to discuss a proposal for a Kerberos security model. The discussion
centered around the question of whether or not a Kerberos security
model should be added to the existing set of security models.  At the
end of the meeting, which was attended by a relatively small number of
people, there was no consensus in the room as to whether or not the WG
should take on the work to develop a Kerberos security model. The
chairs have to address the need and adoption issue with the mailing
list. For the (D)TLS transport of SNMP and related specifications,
interoperability testing is ongoing with the goal to advance the
specifications to Draft Standard.

/js

--

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
Permalink | Reply | 0 comments |

Gmane