[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Sip] Draft writeup for DTLS Framework
We seem to be Done with the DTLS-SRTP Framework!
Here's the draft writeup for draft-ietf-sip-dtls-srtp-framework-03.
Please report any problems (like, maybe I cut-and-pasted the wrong
buffer again) to me and to the list. Thanks!
(1.a) Who is the Document Shepherd for this document?
SIP co-chair Dean Willis will act as the protocol shepherd for this
document.
Has the Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this version is
ready for forwarding to the IESG for publication?
Yes.
(1.b) Has the document had adequate review both from key WG members
and from key non-WG members?
Yes. The document has been closely followed in several working groups,
and by several security-focused persons.
Does the Document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?
The reviews appear to be adequate.
(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective, e.g.,
security, operational complexity, someone familiar with AAA,
internationalization or XML?
The reviews appear to be adequate.
(1.d) Does the Document Shepherd have any specific concerns or issues
with this document that the Responsible Area Director and/or the IESG
should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there
really is a need for it. In any event, if the WG has discussed those
issues and has indicated that it still wishes to advance the document,
detail those concerns here.
There were some concerns about the level of authentication
provided by this document in the face of E.164 nFrom sip-bounces at ietf.org Fri Sep 19 21:10:17 2008
Return-Path: <sip-bounces at ietf.org>
X-Original-To: sip-archive at optimus.ietf.org
Delivered-To: ietfarch-sip-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id A4C3D3A68BD;
Fri, 19 Sep 2008 21:10:17 -0700 (PDT)
X-Original-To: sip at core3.amsl.com
Delivered-To: sip at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id D94C03A68AB
for <sip at core3.amsl.com>; Fri, 19 Sep 2008 21:10:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.478
X-Spam-Level:
X-Spam-Status: No, score=-2.478 tagged_above=-999 required=5 tests=[AWL=0.121,
BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32])
by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id DvlGgF28sF7j for <sip at core3.amsl.com>;
Fri, 19 Sep 2008 21:10:14 -0700 (PDT)
Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164])
by core3.amsl.com (Postfix) with ESMTP id D66F23A685B
for <sip at ietf.org>; Fri, 19 Sep 2008 21:10:12 -0700 (PDT)
Received: from [192.168.2.103] (cpe-76-185-142-113.tx.res.rr.com
[76.185.142.113]) (authenticated bits=0)
by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id
m8K4ANaU003997
(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT);
Fri, 19 Sep 2008 23:10:25 -0500
Message-Id: <468F0B43-A8C9-4167-A30B-DE2960941C51 at softarmor.com>
From: Dean Willis <dean.willis at softarmor.com>
To: SIP IETF <sip at ietf.org>
Mime-Version: 1.0 (Apple Message framework v929.2)
Date: Fri, 19 Sep 2008 23:10:18 -0500
X-Mailer: Apple Mail (2.929.2)
Cc: Cullen Jennings <fluffy at cisco.com>
Subject: [Sip] Draft writeup for DTLS Framework
X-BeenThere: sip at ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sip>,
<mailto:sip-request at ietf.org?subject=unsubscribe>
List-Post: <mailto:sip at ietf.org>
List-Help: <mailto:sip-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sip>,
<mailto:sip-request at ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: sip-bounces at ietf.org
Errors-To: sip-bounces at ietf.org
We seem to be Done with the DTLS-SRTP Framework!
Here's the draft writeup for draft-ietf-sip-dtls-srtp-framework-03.
Please report any problems (like, maybe I cut-and-pasted the wrong
buffer again) to me and to the list. Thanks!
(1.a) Who is the Document Shepherd for this document?
SIP co-chair Dean Willis will act as the protocol shepherd for this
document.
Has the Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this version is
ready for forwarding to the IESG for publication?
Yes.
(1.b) Has the document had adequate review both from key WG members
and from key non-WG members?
Yes. The document has been closely followed in several working groups,
and by several security-focused persons.
Does the Document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?
The reviews appear to be adequate.
(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective, e.g.,
security, operational complexity, someone familiar with AAA,
internationalization or XML?
The reviews appear to be adequate.
(1.d) Does the Document Shepherd have any specific concerns or issues
with this document that the Responsible Area Director and/or the IESG
should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there
really is a need for it. In any event, if the WG has discussed those
issues and has indicated that it still wishes to advance the document,
detail those concerns here.
There were some concerns about the level of authentication
provided by this document in the face of E.164 numbers aumbers and
damage to RFC 4474 Identity done by SBCs. This was extensively
discussed in the WG and the compromise that was reached was
that this document would include a carefully crafted description
of the security properties it provided and that the WG would
independently move forward with work on improving RFC 4474
as necessary.
Has an IPR disclosure related to this document been filed? If
so, please include a reference to the disclosure and summarize the WG
discussion and conclusion on this issue.
No.
(1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?
The WG as a whole understands this document and the consensus
that it should move forward was reasonably strong.
(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is entered into the ID
Tracker.)
No.
(1.g) Has the Document Shepherd personally verified that the document
satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and
http://tools.ietf.org/tools/idnits/). Boilerplate checks are not
enough; this check needs to be thorough. Has the document met all
formal review criteria it needs to, such as the MIB Doctor, media type
and URI type reviews?
There are several outdated references that can be corrected in the RFC
Editor process, but that do not otherwise impact this
specification. There are also some example IP addresses that are
inconsistent with current guidelines. An RFC Editor note will be
provided to correct these errors.
(1.h) Has the document split its references into normative and
informative?
Yes.
Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the strategy for their completion? Are
there normative references that are downward references, as described
in [RFC3967]? If so, list these downward references to support the
Area Director in the Last Call procedure for them [RFC3967].
There is a normative reference to the informational-track RFC 3325. AS
this document provides the most widely-implemented mechanism for
identity expression in SIP and the security provided by this
specification is greatly dependent on the identity mechanism, a full
understanding of the limitations of RFC 3325 is required in order to
understand the impact to this specification if used with RFC 3325.
1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body of the
document?
This document has no IANA considerations.
If the document specifies protocol extensions, are reservations
requested in appropriate IANA registries? Are the IANA registries
clearly identified? If the document creates a new registry, does it
define the proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggest a reasonable name
for the new registry? See [RFC2434]. If the document describes an
Expert Review process has Shepherd conferred with the Responsible Area
Director so that the IESG can appoint the needed Expert during the
IESG Evaluation?
N/A.
(1.j) Has the Document Shepherd verified that sections of the document
that are written in a formal language, such as XML code, BNF rules,
MIB definitions, etc., validate correctly in an automated checker?
N/A.
(1.k) The
IESG approval announcement includes a Document Announcement Write-Up.
Please provide such a Document Announcement Write-Up? Recent examples
can be found in the "Action" announcements for approved documents.
The approval announcement contains the following sections:
Technical Summary
This document is part of a suite of documents that specify a
mechanism for keying the Secure Real-time Transport Protocol (SRTP)
using Datagram Transpornd
damage to RFC 4474 Identity done by SBCs. This was extensively
discussed in the WG and the compromise that was reached was
that this document would include a carefully crafted description
of the security properties it provided and that the WG would
independently move forward with work on improving RFC 4474
as necessary.
Has an IPR disclosure related to this document been filed? If
so, please include a reference to the disclosure and summarize the WG
discussion and conclusion on this issue.
No.
(1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?
The WG as a whole understands this document and the consensus
that it should move forward was reasonably strong.
(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is entered into the ID
Tracker.)
No.
(1.g) Has the Document Shepherd personally verified that the document
satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and
http://tools.ietf.org/tools/idnits/). Boilerplate checks are not
enough; this check needs to be thorough. Has the document met all
formal review criteria it needs to, such as the MIB Doctor, media type
and URI type reviews?
There are several outdated references that can be corrected in the RFC
Editor process, but that do not otherwise impact this
specification. There are also some example IP addresses that are
inconsistent with current guidelines. An RFC Editor note will be
provided to correct these errors.
(1.h) Has the document split its references into normative and
informative?
Yes.
Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the strategy for their completion? Are
there normative references that are downward references, as described
in [RFC3967]? If so, list these downward references to support the
Area Director in the Last Call procedure for them [RFC3967].
There is a normative reference to the informational-track RFC 3325. AS
this document provides the most widely-implemented mechanism for
identity expression in SIP and the security provided by this
specification is greatly dependent on the identity mechanism, a full
understanding of the limitations of RFC 3325 is required in order to
understand the impact to this specification if used with RFC 3325.
1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body of the
document?
This document has no IANA considerations.
If the document specifies protocol extensions, are reservations
requested in appropriate IANA registries? Are the IANA registries
clearly identified? If the document creates a new registry, does it
define the proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggest a reasonable name
for the new registry? See [RFC2434]. If the document describes an
Expert Review process has Shepherd conferred with the Responsible Area
Director so that the IESG can appoint the needed Expert during the
IESG Evaluation?
N/A.
(1.j) Has the Document Shepherd verified that sections of the document
that are written in a formal language, such as XML code, BNF rules,
MIB definitions, etc., validate correctly in an automated checker?
N/A.
(1.k) The
IESG approval announcement includes a Document Announcement Write-Up.
Please provide such a Document Announcement Write-Up? Recent examples
can be found in the "Action" announcements for approved documents.
The approval announcement contains the following sections:
Technical Summary
This document is part of a suite of documents that specify a
mechanism for keying the Secure Real-time Transport Protocol (SRTP)
using Datagram Transport Layer t Layer Security (DTLS). Together, these
protocols provide for in-band establishment of secure multimedia
sessions without dependencies on external authentication
infrastructures. This document specifies the SIP framework for
DTLS-SRTP. A companion document, draft-ietf-avt-dtls-srtp,
specifies the SRTP portion.
Working Group Summary
This document is a product of the Session Initiation Protocol
(SIP) Working Group. It was developed in response to coordinated
meetings held with several working groups, and in consideration of
several competing specifications.
Document Quality
There are at least two known implementations of earlier versions of
this draft, one Open Source and one commercial. Several
implementors have expressed interest in implementation and
deployment of the final version.
Personnel
The Document Shepherd for this document is Dean Willis, and the
responsible Area Director is Cullen Jennings.
RFC Editor Note to Accompany Pub Request:
RFC Editor:
Please replace all occurrences of the string "192.168.1" with "192.0.2".
Please replace references to RFC 3280 with references to RFC 5280.
Please replace references to RFC 3546 with references to RFC 4366.
Please update any -draft references as appropriate.
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip
Security (DTLS). Together, these
protocols provide for in-band establishment of secure multimedia
sessions without dependencies on external authentication
infrastructures. This document specifies the SIP framework for
DTLS-SRTP. A companion document, draft-ietf-avt-dtls-srtp,
specifies the SRTP portion.
Working Group Summary
This document is a product of the Session Initiation Protocol
(SIP) Working Group. It was developed in response to coordinated
meetings held with several working groups, and in consideration of
several competing specifications.
Document Quality
There are at least two known implementations of earlier versions of
this draft, one Open Source and one commercial. Several
implementors have expressed interest in implementation and
deployment of the final version.
Personnel
The Document Shepherd for this document is Dean Willis, and the
responsible Area Director is Cullen Jennings.
RFC Editor Note to Accompany Pub Request:
RFC Editor:
Please replace all occurrences of the string "192.168.1" with "192.0.2".
Please replace references to RFC 3280 with references to RFC 5280.
Please replace references to RFC 3546 with references to RFC 4366.
Please update any -draft references as appropriate.
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip