Subject: [Gen-art] A *new* batch of IETF LC reviews - March 8th, 2006

From: "Mary Barnes" <[email-masked]>
Date: Wed, 8 Mar 2006 13:47:12 -0600

Hi all,

Here's the latest round of LC assignments: 
http://www.alvestrand.no/ietf/gen/art/gen-art.html 
http://www.alvestrand.no/ietf/gen/art/gen-art-by-reviewer.html 

Thanks, 
Mary. 

--------------------------- 
Reviewer: Scott Brim

- 'MIME type registration for RTP Payload format for H.224 '
   <draft-ietf-avt-mime-h224-05.txt> as a Proposed Standard

IETF LC ends on 2006-03-16.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-avt-mime-h224-05.txt

--------------------------- 
Reviewer: Spencer Dawkins

- 'RTP Payload Format for H.261 Video Streams '
   <draft-ietf-avt-rfc2032-bis-13.txt> as a Proposed Standard

IETF LC ends on 2006-03-16.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-avt-rfc2032-bis-13.txt

--------------------------- 
Reviewer: Elwyn Davies

- 'Transferring MIB Work from IETF Bridge WG to IEEE 802.1 WG '
   <draft-harrington-8021-mib-transition-01.txt> as an Informational RFC

IETF LC ends on 2006-03-17.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-harrington-8021-mib-transition
-01.txt

   This document describes the plan to transition responsibility for
   bridging-related MIB modules from the IETF Bridge WG to the IEEE
   802.1 WG, which develops the bridging technology the MIB modules are
   designed to manage.

This is not a WG document, but has been discussed quite extensively
already. The document is intended as Informational RFC. Therefor a 
2 week IETF Last Call is being used for IETF community-wide review.

--------------------------- 
Reviewer: Joel Halpern

- 'Internet X.509 Public Key Infrastructure Subject Identification
Method
(SIM)'
   <draft-ietf-pkix-sim-07.txt> as a Proposed Standard

To distinguish among multiple individuals with the same name, it may
be necessary to include in a certificate some personal data that may
be considered sensitive.  Examples of such personal ID data are U.S.
social security numbers and similar national ID numbers in other
countries.  A certificate subject may be willing to disclose this data
to some relying parties (RPs), but not to everyone who may have access
to his/her certificate.  Recall that certificates are often passed
over the Internet without encryption, stored in repositories that may
allow public access, and so on.  Thus a wide range of possible
adversaries will have an opportunity to conduct offline attacks that
seek to reveal sensitive ID data if it is part of a certificate.

SIM is a technique for managing this problem of selective disclosure
of such sensitive (though not secret) ID data in the context of X.509
certificates.  The SIM data is carried as a subject alternative name
(SAN) using the Privacy-Enhanced Personal Identifier (PEPSI) format,
also defined in this document.  Because this data is carried in the
SAN, the subject name must itself be unique without the further
qualification provided by this other data, consistent with X.509 and
PKIX certificate requirements.

The PEPSI value is the result of applying a two-pass hash function to
the SIM data, employing a user-supplied password and a Registration
Authority supplied random number.  An attacker trying to confirm a
guessed SIM value cannot employ a pre-computed dictionary attack, due
to the use of the random number.  Nonetheless, selection of a poor
password by a user does allow an attacker to mount a focused, offline
guessing attack on a PEPSI value.

Three scenarios for use of SIM are described:
  
    -  If a relying party knows the user's SIM value, and uses
       it to uniquely identify the user, the RP can confirm the
       user's identify through processing of the certificate and
       user disclosure of the password to the RP via a secure
       channel.

    -  If the RP does not know the SIM value, it can be disclosed
       to the RP via secure transfer of the password, and processing
       of the certificate by the RP, e.g., so that the RP can
       acquire the SIM value for future use.

    -  Finally, knowledge of the password by the user can be
       employed as a secondary authentication mechanism, in
       addition to the user's knowledge of his private key,
       without exposing the SIM data to an RP.

IETF LC ends on 2006-03-20.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-pkix-sim-07.txt

--------------------------- 
Reviewer: John Loughney

- 'Simple Authentication and Security Layer (SASL) '
   <draft-ietf-sasl-rfc2222bis-15.txt> as a Proposed Standard

IETF LC ends on 2006-03-20.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-sasl-rfc2222bis-15.txt

--------------------------- 
Reviewer: Spencer Dawkins

- 'OSPF Version 2 Management Information Base '
   <draft-ietf-ospf-mib-update-09.txt> as a Proposed Standard

IETF LC ends on 2006-04-03.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-ospf-mib-update-09.txt

------------------------

_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art

---

From: Scott W Brim <[email-masked]>
Date: Thu, 09 Mar 2006 06:58:03 -0500

draft-ietf-idwg-idmef-xml-15 is overdue (my confusion) -- Brian already
voted no objection.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 09 Mar 2006 16:12:04 -0500

This document appears to be ready for publication as a proposed standard.

Yours,
Joel

At 02:47 PM 3/8/2006, Mary Barnes wrote:
>- 'Internet X.509 Public Key Infrastructure Subject Identification Method
>(SIM)'

---

From: Scott W Brim <[email-masked]>
Date: Sat, 11 Mar 2006 21:34:10 -0500

For info on gen-art please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html

Fine except for one thing.  The abstract says "conversional video
applications".  Should that be "conversational"??