IESG Narrative Minutes
Narrative Minutes of the IESG Teleconference on 2011-03-03. These are not an official record of the meeting.
Narrative scribe: Barry Leiba (The scribe was sometimes uncertain who was speaking.)
The scribe had difficulty with Lars's connection, and had a hard time understanding him, and so apologizes that the notes about what he said are spotty.
Corrections from:
1 Administrivia
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Items
Telechat:
Telechat:
Telechat:
Telechat:
2.1.2 Returning Items
Telechat:
2.2 Individual Submissions
2.2.1 New Items
Telechat:
2.2.2 Returning Items
3. Document Actions
3.1 WG Submissions
3.1.1 New Items
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
3.1.2 Returning Items
3.2 Individual Submissions Via AD
3.2.1 New Items
Telechat:
Telechat:
Telechat:
3.2.2 Returning Items
3.3 IRTF and Independent Submission Stream Documents
3.3.1 New Items
3.3.2 Returning Items
3.3.3 For Action
Telechat:
1250 EST break
1255 EST back
4 Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
Telechat:
Telechat:
4.1.2 Proposed for Approval
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
Telechat:
4.2.2 Proposed for Approval
5. IAB News We can use
6. Management Issues
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
7. Agenda Working Group News
1325 EST Adjourned
(at 2011-03-03 07:29:51 PST)
draft-ietf-netconf-rfc4742bis
1) 4741bis says: "The authentication process MUST result in an authenticated
client
identity whose permissions are known to the server. The
authenticated identity of a client is commonly referred to as the
NETCONF
username. The algorithm used to derive the username is
transport protocol
specific and in addition specific to the
authentication mechanism used by the
transport protocol. NETCONF
transport protocols therefore MUST explain how a
NETCONF username is
derived from the authentication mechanisms supported by
the transport
protocol.
The access permissions of a given client, identified by its NETCONF
username, are part of the configuration of the NETCONF server. These
permissions MUST be enforced during the remainder of the NETCONF
session. The details how access control is configured is outside the
scope of this document."
4742bis says: "How the NETCONF Server extracts the SSH user name from the SSH
layer
is implementation-dependent."
This is not an explanation. Assuming an operator must specify access control
rights for a user in the configuration o fthe server, it is important that the
operator understands what the netconf username(s) will be. That is presumably
why it is important for the Netconf transport protocol specification to explain
the algorithm for deriving the username.
RFC5592 defines an SSH subsystem for use with SNMP, and has had to deal with
similar issues, including constraints about not changing the username associated
with a session, allowing "user@host" style naming, etc.
Maybe those are not
needed for netconf, but the above "implementation-dependent" explanations seems
woefully inadequate.
1) The IANA section does not specify that the assigned port is a TCP port. should it?
In general I support publication of this document. However I would like to
discuss the following issue before I can recommend its approval:
1) I support David's DISCUSS about lack of information about username
extraction.
I suspect I am disclosing my lack of netconf clue, but here goes: Why is the example in section 4.2 (chunked encoding) declaring the base1.0 namespace? I thought that base1.1 support is required of both the server and client to use chunked encoding...
This is updated to add two new comments from the SECDIR review. #1) Sec 3.1: 2nd para, 1st sentence: Should the "must" in the first paragraph be a "MUST"? #2) Sec 4.2: Would any XML decoding error cause termination as stated at the end of 4.2? E.g. some unknown xmlns value or something? #3) If it's worth changing the framing protocol at all, which I'm willing to accept as a given, it is far from obvious to me that the current negotiated upgrade is the right way to do it, as this will require implementation of the old bad mechanism forever. Switching to a new SSH subsystem name seems like a much simpler solution. #4) As a matter of stylistic consistency with the last several decades of Internet protocols, the delimiter sequence in the new framing protocol should have been <CRLF>, not <LF>.
draft-ietf-netconf-4741bis
Rob Enns has left Juniper Networks. We need an updated affiliation for him.
Section 2 should have a requirement that NETCONF transport that are to be used over the Internet MUST implement congestion control, in accordance with RFC2914. It can also simply note that all NETCONF transports that use TCP (such as the SSH transport) automatically fulfill this requirement. (This really is a no-brainer. I just want to prevent a future argument when someone wants to do a "lightweight" NETCONF transport over UDP...)
I am entering a No Objection position on the basis of the Yes ballots fromt the Ops ADs. Appendix C seems to claim that "this value is pre-determined by RFC 4741" but since 4741 is now obsoleted (by this document) you should find some new text.
1) should there be constraints on the basic format of username? if it is
expected to be specified by an operator in config files or databases, should it
be human-readable? ascii? utf-8?
2) should the format be predictable, so the operator can determine what the NC
username will be, given a knowledge of the corresponding identifier in the
secure transport protocol?
3) commit MUST revert at 600 secs, but timeout is configurable., what if
somebody sets it to 700 seconds? MUST it still revert at 600? Can a low timeout
cause a denial of service?
1) copyright in yang module needs updating. 2) appendix F doesn't mention dropping the local file requirement for URLs, 3) terminology should probably define username, not user. It is doubtful username is commonly referred, since it did not exist in 1.0. 4) I found the use of RFC2119 laniguage rather inconsistent. Some uses of "can" probbaly should have been MAY. Some uses of "are" probbaly should have been MUST, to ensure interoperability. 5) I support Lars' Discuss. There is no requirement to use a transport protocol that provides congestion control. If a transport is used that does not already provide congestion control, then the NC transport should provide congestion control. It is RECOMMENDED to use an existing transprt standard that provides congestion control.
Please add a sentence to the Abstract that indicates that this document obsoletes RFC 4741.
(1) 2.2. paragraph 1 - last sentence is awkward. In general connections are encrypted "in" an algorithm (e.g., AES) or "using" a protocol (e.g., TLS). Suggest: s/encrypted in TLS [16] or SSH [14]/encrypted using TLS [16] or SSH [14]/ (2) 3.1. Namespace Should this text reference the namespace base:1.1 instead of base:1.0 ?? (3) The example in 6.2.2 Attribute Match Expressions references containment nodes and selection nodes, which are described in 6.2.3 and 6.2.4, respectively. It might be cleaner to reorder as 6.2.2 Containment Nodes, 6.2.3 Selection Nodes, and 6.2.4 Attribute Match Expressions so that concepts are introduced sequentially (4) Section 8.1 The following sentence implies that clients can attack other sessions by guessing session-ids: A server receiving a <session-id> element MUST close the NETCONF session. I believe the intent was as follows: A server receiving a <hello> element that includes a <session-id> element MUST ignore the session-id and close the NETCONF session. If that is the intent, I suggest the latter wording. (5) Section 9. Security Considerations, paragraph five states: Configuration information is by its very nature sensitive. Its transmission in the clear and without integrity checking leaves devices open to classic eavesdropping attacks. Configuration information often contains passwords, user names, service descriptions, and topological information, all of which are sensitive. Because of this, this protocol SHOULD be implemented carefully with adequate attention to all manner of attack one might expect to experience with other management interfaces. The clause "and without integrity checking" is not relevant to eavesdropping attacks. Suggest: s/classic eavesdropping attacks/classic eavesdropping and false data injection attacks/
1. DTDs are forbidden (presumably you mean internal or external DTD subsets in accordance with section 2.8 of the XML specification). What about comments, processing instructions, and internal or external entity references? 2. In Section 6.2.5, 'for which the <name> element is equal to "fred"' is more precisely expressed as 'for which XML character data of the <name> element is equal to "fred"'. (The same text occurs in Section 6.4.5.) 3. Section 6.4.3 states: In a real data model, the <company-info> would not likely be returned with the list of users for a particular host or network. Why not? 4. In Section 7.5, is the server allowed to terminate a lock for reasons other than session closure? If not, it appears than an entity could maintain a lock indefinitely. 5. In Appendix B, it seems that some of the enumerated datatypes could be changed from xs:string to something more restrictive, such as xs:NMTOKEN (e.g., error types, error tags, error severity, edit operation type).
draft-ietf-hokey-ldn-discovery
I agree with others that the document must be changed so that its title, abstract, and the option name match the use for ERP. This is not about general domains (e.g., DNS).
Small suggestion for clarity: s/EAP domain/domain/ in the Abstract., for those of us who leap to associating "domain" with "DNS"...
Acronyms need to be expaneded on first use in the body of the document. For example, EAP, DSRK, etc.
[Updated 2011-03-02 to reference the apps-review team review by Eliot Lear.]
1. The reference to RFC 3315, along with the lack of a reference to RFC 5891,
seems to imply that internationalized domain names are not supported. If so,
please make that clear in the specification.
2. The apps-review team review raised the following major issues:
The option specified in this draft is to be used for the specific
purpose of ERP, and may not be appropriate for other uses, such as use
in a search list. See Section 2 of RFC 5296. Both the option name and
the text should make this clear.
While this is an Applications Area review, the Security Considerations
section should still conform to the requirements of RFC 3552.
1. Please spell out FQDN and other relevant acronyms (e.g., perhaps AAA) on first use. 2. Section 5 has "DHPv6" instead of "DHCPv6". 3. The apps-review team review raised the following issue: This document also specifies a length limitation of 256 octets that does not take into account issues raised by RFC 4282. My recommendation would be to either match or reference the text in RFC 4282.
#1) Is there no way that a relay agent might be acting on behalf of many
domains without knowing? If so, then section 5 may need a few more words.
#2) Section 6 says authentication is needed. I assume it's mutual
authentication, but this should be explicitly stated.
#3) Section 6, for how long must replays be detected? (And by whom?) How can
that be done? (E.g. for a mobile device)
#1) In the security considerations can you say something more about what happens if mutual authentication is not performed. #2) Section 5 should indicate why the DHCPv6 relay should include the LDN. #3) Sec 3: Can this option be used other than "after full EAP authentication"? Either way, just say so.
draft-ietf-payload-rfc4695-bis
An easy Discuss that can be resolved with just a few words.
idnits points out...
-- The draft header indicates that this document obsoletes RFC4695,
but the abstract doesn't seem to mention this, which it should.
It should also be discussed in the Introduction.
I would also say that Appendix F (changes from 4695) should be pulled
back into the body of the document, but this is not important.
(See also the Comment from Russ Housley)
Section 1.2 In this document, the packet bitfields that share a common name often have identical semantics. This left me wondering how I find the cases where they have common names but different semantics.
Please add a sentence to the Abstract that indicates that this document obsoletes RFC 4695.
My apologies for spending so little time to review this document, but the
following things caught my attention:
1).
11. IANA Considerations
This document does not change any of the registrations in RFC 4695.
Therefore, this document does not require any IANA actions, apart from
updating the references to RFC 4695 to point to this document.
I don't think this is Ok. Please correct me if I am wrong, but this document has
updated ABNF for various parameters specified in RFC 4695. This clearly updates
the MIME type registration.
I think the right thing to do here is to keep the MIME type registration from
RFC 4695 in this document.
2). Somewhat related to #1: RFC 4695 registers audio/mpeg4-generic MIME type.
audio/mpeg4-generic MIME type registration on
<http://www.iana.org/assignments
/media-types/audio/index.html> doesn't point to
RFC 4695 or this draft. This
seems to be an omission.
And again, correct me if I am wrong, but it looks like
the MIME type registration is implicitly updated due to changes to the ABNF of
various MIME type parameters.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
This reference needs to be Normative. No extra IETF LC is needed to make this
change, as this RFC is already in the DownRef registry.
Because this is a -bis document, I am entering the following issues as Comment-
level (as opposed to DISCUSS-level), however I would like to ask to serious
consider fixing these as well:
D. Parameter Syntax Definitions
mime-type = "audio" / "application"
mime-subtype = token
;
; See Appendix C.6.2 for registration
; requirements for rinit type/subtypes.
The mime-subtype definition should be pointing to the definition in RFC 4288,
Section 4.2:
4.2. Naming Requirements
type-name = reg-name
subtype-name = reg-name
reg-name = 1*127reg-name-chars
reg-name-chars = ALPHA / DIGIT / "!" /
"#" / "$" / "&" / "." /
"+" / "-" / "^" / "_"
In RFC 4695:
11.3. asc Media Type Registration
Media type name:
audio
Subtype name:
asc
[...]
Restrictions on usage:
This type is only defined for data object (stored file)
transfer. The most common transports for the type are
HTTP and SMTP.
And there is no registered file extension? I think this is a serious omission
for something which can be stored in a file.
In the IANA Considerations Section: > This document does not change any of the registrations in RFC 4695. Therefore, this document does not require any IANA actions, apart from updating the references to RFC 4695 to point to this document. It looks to me that both documents (this one and RFC 4695) need to be referenced in the IANA pages. The reason is that while this document obsolets RFC 4695 it does not carry the text that refers to the creation of the registries.
#1) Since this is a bis document, I presume it's been used for a while. Maybe the tense should change in intro to reflect this? Likewise, the original premise of 4965 was to allow musicians to be in different locations but still jam together - did it work?
draft-ietf-sipcore-199
INTRODUCTION, paragraph 2: > Response Code for Indication of Terminated Dialog Add something to the title that makes it clear this is for SIP? Section 3., paragraph 1: > REQ 1: It must be possible to indicate to the UAC that an early > dialog has been terminated before a final response is sent. I don't understand the purpose of including this single requirement in this specification document. At least not without further explanation.
The document does not say what track it is targeting. I assume from the ballot that it is intended as Standards Track. Please can you confirm and update the document header. The abbreviations UAC and UAS will need to be expanded in the Abstract and on first usage in the body text.
The Gen-ART Review by Avshalom Houri on 26 Jan 2010 suggested adding references to other relevant RFCs in the Security Considerations. A few editorial changes were suggested. Please consider these changes.
The draft needs to be explicitly clear about what conditions it helps in. The
current text is not clear enough given that many people end up debating it and
or confused. I think this is just a matter of getting more explicitly about
these points and deleting any ones where it is not clear exactly what cases it
helps in. We just need to get these to the point where it is clear that they are
factually correct.
1. Codec release - when resources for a specific codec has been
reserved only for the stream that is terminated. In that case the
resources associated with that codec can be released.
I don't understand what resource is released. On some very old large gateways
that loaded codecs into the DSP du to DSP memory limitations, I understand what
codec released means but that does not make sense in this context. Please
explain in email what gets released and in what real world scenarios this occurs
then we can sort out what the draft needs to say. I obviously consider mobile
batter operated devices over wireless to be very important use cases.
2. Pre-conditions - when the dialog is terminated, procedures and
resources associated to the pre-conditions for that dialog can be
released.
Please clarify this to around the allocated bandwidth. I would also like to
understand in what real world scenarios this is going to result in additional
dialogs being set up once the bandwidth becomes available. You need to walk me
through a scenario of how this is going to work.
3. In-band security negotiation - when the dialog is terminated,
procedures and resources associated with the in-band security
negotiation for that dialog can be released.
Ditto on this.
You wrote "[Christer] Whatever procedures takes place on the media plane in
order to establish the security associated, and resources reserved in order to
deal (encrypt/decrypt) with the secure media itself." I still don't understand
what resources. Jari said that if a slow UA was still trying to set up a
security associations by the time the 199 arrived, this could allow it to stop
that and it might take a long time due to CPU speed and doing PKi computations.
If this is what you mean, I'd be interested in understanding when that might
happen. It does make sense but I don't understand when it would occur.
4. ICE [I-D.ietf-mmusic-ice] mechanism - when the dialog is
terminated, procedures and resources associated with the ICE related
in-band procedures for that dialog can be released.
In email you mentioned that it is the sending of keep alives that can be
stopped. This is a good answer and makes sense. Can you update the text to say
that and also mention how frequently they are sent and what sort of scenarios
benefit from this optimization.
5. Limited access resources - in case of forking and multiple stream
it may not be possible to allow early media on all dialogs, so media
sessions associated with some dialogs may e.g. be set to "inactive".
When a dialog is terminated, media sessions associated with other
dialogs can be allowed.
From email "[Christer] The probably most common scenario is when an application
server in the network creates an early dialog with the UA in order to send an
announcement, while the INVITE is forwarded towards the remote UA(s). There are
specified procedures (in TISPAN and 3GPP) where this occur, and I believe this
mechanism has also been discussed on the IETF SIP lists."
Can you help educate me about theses a bit more. The ones I saw before involved
the announcement finishing before the PSTN got the call.
6. Secure media selection - when SRTP is used to encrypt the media.
I'm still not following what this allows that would not be otherwise possible
without the 199. I did read the Note about SRTP.
I'm not understanding why 199 allows the SBC to do something it can not do today
in the section where latching is discussed. Typically "Latching" in SBC is not
at all what you describe here. It is the process by which an SBC decide to send
RTP to a IP address that is different than what is in the SDP. Can walk me
through in email what is going on propose some text.
In the case of early ring tone termination where say a PSTN gateway roles over
to voicemail, I don't see who this will accelerate the move in any useful way
from the PSTN ringback tone to the voicemail server media.
I see no reason to allow this in a Require or proxy-Require and think that
should be a MUST NOT. As you can tell, I think the value of this draft is
somewhat limited but I am OK with publishing it as long as it does no harm. I
view adding a require or proxy-require as something that would reduce
interoperability of SIP call in a significant way and thus be harmful. I am very
unlikely to be convinced to change my position on this one but I would be happy
to hear concrete reasons why this needs to be a SHOULD.
It's unclear to me what Reason code to insert or why this is a MUST. The reason
code seems non necessary for the describes uses of this mechanism. I read your
email and it did not help me understand why the Reason was mandated. Mandating
things that are not needed and can be separated seldom turns out to be good [as
you rightly pointed out in putting the keep-alives in the same draft as rest of
outbound]. Unless there is a compelling technical reason for this we should not
do it.
The actual specification of how you deal with SDP in a 199 containing an offer
is probably all correct in the draft but it is very difficult to understand the
logic that lead to this and what one is supposed to do. Could you rephrase it be
clear on exactly how this interacts with invites with no offer and explain why
it needs to work the way it does.
The not sending things reliably that have a Require: 100rel seems like it will
break some IDS, firewalls, and middles boxes that are expecting any 1xx to
reliable since that was signaled. I'd like to see text that helped explain this.
I'm not asking you to change this - I am asking to discuss and point out the
implications of if.
I would like to see it very clear in the document at if you receive SDP in a
199, the UA MUST ceases sending all media on the RTP streams associated with
that dialog. I would not want this to be used in an attack where one could send
an an authenticated 199 and cause devices to star sending media to random 3rd
parties that showed up in the SDP.
I imagine more than one of these thing may just be talking past each other so
I'm glad to have a phone call if that helps clear any of this up. I'm sure some
rounds of email will be needed.
I agree that Experimental for this document is going to be better. I don't think the document is doing a very good job convincing readers about utility of this mechanism. At least not until it starts describing detailed use cases. 4.1. Examples of resource types NOTE: When using SRTP [RFC3711], the secure media stream is bound to the crypto context setup for the dialog, and can be identified using the MKI (if used) of SRTP. Please expand the acronym on first use. If the client only has a single early dialog (other early dialogs MAY not have been established, or they MAY have been established and It doesn't look like use of these 2 MAYs is correct - they don't describe requirements. later terminated) and a 199 response is received for that early dialog, the client terminates the early dialog. Afterwards, the client SHOULD act as before the first early dialog was established. 4.2. Examples of policy procedures 2. SBC early media selection - when an SBC is used to control which Please expand the acronym on first use. media is processed and forwarded. In many cases, the SBC only processes media associated with a single early dialog. Typical for NAT traversal, the SBC often "latches" onto a media stream. If a 199 response is received, the SBC can choose to start processing media associated with another dialog. If the SBC performs latching, it can trigger a "re-latch" onto a new media stream when the 199 response is received.
Section 1 states The 199 response code is an optimization, which allows the UAC to be informed about terminated early dialogs. However, since the support of the 199 response is optional, a UAC cannot assume that it will always receive a 199 provisional response for all terminated early dialogs. Section 4 seems to imply that there are some applications that will not work unless 199 is supported: The UAC SHOULD NOT insert the 199 option- tag in the Require header, unless the particular session usage requires the UAS to support the response code. Also, the UAC SHOULD NOT insert the 199 option-tag in the Proxy-Require header, unless the particular session usage requires every proxy on the path to support the response code. Are these two sections in conflict?
The introduction is difficult to understand. It would be helpful to provide a picture of the scenario that motivates this document, or at least to provide a forward reference to the "swim lane" diagrams in Section 9.
#1) Sec 1: Can you provide an example of policy related decision? In addition, SIP entities might also use the 199 response to make policy related decisions related to early dialogs. #2) Sec 5: This is a little hard to parse (it's all one sentence): If a UAS receives an initial dialog initiation request, with a Supported header field that contains a "199" option-tag, it SHOULD NOT send a 199 response on an early dialog associated with the request, before it sends a non-2xx final response, unless it e.g. has been configured to do so due to lack of support of the 199 response code by forking proxies or other intermediate SIP entities, or it is used in an environment that specifies that it shall send a 199 response before sending a non-2xx response. #3) I'm trying to reconcile the statement in the 2nd to last para of Sec 5, which says that the 199 is only for informational purposes, with the MUST NOT In the last paragraph. If it's informational then why is it a MUST NOT?
draft-bryan-metalinkhttp
I've cleared my DISCUSS.
1) Resolved.
2) Is there a registry for the various attributes references in this
document, including "pri", "pref", "geo", etc.? If not, in my opinion
it would be beneficial to give a list and some formal definitions of
the attriubtes; at least, some indication that the attributes are
defined in this document.
(added 2011/3/3) The latest rev almost resolves this comment. My
remaining comment is admittedly pedantic and just a nit, based on
avoiding the use of passive voice:
The following OPTIONAL attributes are defined:
o "depth" : mirror depth in Section 3.4.
o "geo" : mirror geographical location in Section 3.2.
o "pref" : a preferred mirror server in Section 3.3.
o "pri" : mirror priority in Section 3.1.
Is this text the authoritative definition for the OPTIONAL attributes
or are they defined somewhere else and the definitions repeated here?
INTRODUCTION, paragraph 4:
> This document specifies Metalink/HTTP: Mirrors and Cryptographic
> Hashes in HTTP header fields, a different way to get information that
> is usually contained in the Metalink XML-based download description
> format. Metalink/HTTP describes multiple download locations
> (mirrors), Peer-to-Peer, cryptographic hashes, digital signatures,
> and other information using existing standards for HTTP header
> fields. Clients can use this information to make file transfers more
> robust and reliable.
DISCUSS: The document title and this summary aren't really accurate.
In addition to describing how to store Metalink info in HTTP header
fields, a large part of the document (Section 7) is actually
specifying how Metalink clients MUST/SHOULD/MAY operate.
Section 3.3., paragraph 1:
> There are two types of mirror servers: preferred and normal.
> Preferred mirror servers are HTTP mirror servers that MUST share the
> same ETag policy as the originating Metalink server and/or MUST
> provide Instance Digests using the same algorithm as the Metalink
> server.
DISCUSS: Section 1 said "SHOULD share the same ETag policy" - which is
it?
Section 7., paragraph 13:
> If the object is large and gets delivered slower than expected, then
> the Metalink client MAY start a number of parallel ranged downloads
> (one per selected mirror server other than the first) using mirrors
> provided by the Link header fields with "duplicate" relation type.
> Metalink clients SHOULD use the location of the original GET request
> in the "Referer" header field for these ranged requests.
DISCUSS: I realize that this spec doesn't really cover the client, but
I find this description of permitted client operation problematic.
What it basically says is "if the download is slow, open more
connections." This is NOT a good general practice. There need to be
limits on the number of parallel connections, ideally based on
observing how the aggregate throughput changes as connections are
opened - blindly opening connections once the path bottleneck is
filled is pointless. (There is some text later in this section that
goes in this direction, but not far enough.)
Section 3.2., paragraph 1: > Entries for a mirror servers can have a "geo" value, which is a > [ISO3166-1] alpha-2 two letter country code for the geographical > location of the physical server the URI is used to access. A client > can use this information to select a mirror, or set of mirrors, that > are geographically near (if the client has access to such > information), with the aim of reducing network load at inter-country > bottlenecks. s/can/MAY/? The document is generally pretty sloppy in its use of RFC2119 terms; it would be very good if the authors would go over it once more. Section 4., paragraph 1: > Entries for metainfo files, which describe ways to download a file > over Peer-to-Peer networks or otherwise, are specified with the Link > header fields [RFC5988] and a relation type of "describedby" and a > type parameter that indicates the MIME type of the metadata available > at the URI. Since metainfo files can sometimes describe multiple > files, or the filename may not be the same on the Metalink server and > in the metainfo file but still have the same content, an optional > name parameter can be used. s/optional/OPTIONAL/ and/or s/may/MAY/ Section 4.1., paragraph 1: > Full Metalink/XML files for a given resource can be specified as > shown in the example in Section 4. Specify-by-example isn't how things are usually done in the IETF. It would be good to have an actual specification.
Section 1... "extremely minimal" means what? It either minimal or it isn't. --- Section 3.1 Entries for mirror servers are listed in order of priority (from most preferred to least) or have a "pri" value, where mirrors with lower values are used first. This is purely an expression of the server's preferences; it is up to the client what it does with this information, particularly with reference to how many servers to use at any one time. There is a contradiction between "are used first" and the second paragraph that says the client can do what it likes. Maybe the word "priority" and the "pri" value are poor choices since they reflect only a preference.
From the GenArt review:
Also, is there a risk the initial server could cause a loop by pointing to
_itself_?
I support Sean's discuss on signature formats. There is nothing wrong with OpenPGP, and it would be fine to make that the mandatory to implement, but the installed base with X.509 would seem to justify including S/MIME signatures. I also share Robert's and Peter's concerns about amplification and DoS attacks.
1. If the draft is based on the experiences made in a project the community would like to know more on the project. It would be good to mention in the Introduction section of the draft the open source project, what it does and the experience made based on the project, and also provide a reference to the project in the references section. 2. The document does not have a Terminology and Abreviations section, which would be very useful to make it more readable
(I'm moving these points to a comment based on -21 and the email conversation that followed. The changes discussed in that email thread will satisfy these points.) 1) What prevents a malicious server from returning a 200 with many Link: headers, all indicating rel=duplicate, perhaps indicating non-overlapping subsets of the entity, and all pointing to a victim, driving many, possibly parallel, connection attempts? 2) When a Link (indicating an HTTP resource) is followed, does anything prevent that referenced server from also replying with MetaLink headers in its response? If not, what prevents loops, intentionally or unintentionally created, from being followed? If a client would automatically follow these, especially in parallel, exponential attacks against the victims in item 1) are possible. At the very least, a client could be sent into an infinite ping-pong loop.
draft-ietf-shim6-multihome-shim-api
The description of SHIM_LOC_LOCAL_PREF in section 6.4 is unclear to
me. Does this mecahnism set the preferred local locator or the
preference values (lc_prio and lc_weight) on a local locator? Does it
get the currently preferred locator or the preference values for the
specified locator? The same questions apply to section 6.5.
lc_proto is not specified in any of the examples in section 6, while
lc_ifidx and lc_flags are explicitly set to 0 even in the cases where
they are not used (e.g., section 6.4). Is lc_proto a "don't care";
does it need to be set to 0 to show no NAT is involved; is it set to a
non-zero value to indicate a NAT will be traversed?
In section 8:
lc_proto
Internet Protocol number for the protocol which is used to handle
locator behind NAT. Typically, this value is set as UDP (17) when
the locator is a UDP encapsulation interface.
What is the value of lc_proto if the locator is not behind a NAT, or
is there some other way to indicate that the lcoator is not behind a
NAT? "Typically" is imprecise; if the value is not always
IPPROTO_UDP, where are the values formally defined?
Also in section 8:
lc_addr
Contains the locator. In the case where a locator whose size is
smaller than 16 bytes, an encoding rule should be provided for
each locator of a given address family. For instance, in case of
AF_INET (IPv4), the locator should be in the format of an IPv4-
mapped IPv6 address as defined in [RFC4291].
Why not "must be provided"? Where are these encoding rules provided?
Why not "in case of AF_INET (IPv4), the locator is encoded in the
format of [...]"
Still in section 8:
lc_ifidx
Interface index of the network interface to which the locator is
assigned. This field is only used in a read (getsockopt())
operation.
But the example in section 6.8 seems to indicate the use of lc.ifidx
with setsockopt(). I recommend dopping the last sentence here in
section 8 and leaving the explanation of the use of lc_ifidx (and
lc_flags, which also appears to be unused in some setsockopt() calls)
to the specific specifications in section 6.
The fourth and fifth paragraphs of the Introduction would fit better someplace else; perhaps in section 2, renamed "Terminology and Background". In section 5, what is a "context"? Third bullet in section 5: s/Notification from applications/Notification from applications and upper layer protocols/ (for consistency throughout the text of this bullet). (Nit) Fifth bullet in section 5: s/for the/for a/ (Clarification) "The host" seems imprecise; is it really the shim sub-layer that makes the substitution? Ninth bullet: define "deferred context" (as well as "context"?) in section 3. In the description of SHIM_ASSOCIATED, I suggest leaving out the specific parameter values (0/1), as those values are specified in section 6.1; in fact, there appears to be a third value specified for SHIM_ASSOCIATED (2) in section 6.1 that is not mentioned in the earlier description. The indication of which parameters are unused in a given setsockopt() call, as in this text from section 6.4: Note that some members of the shim_locator (lc_ifidx and lc_flags) are ignored in the set operation. is not consistently specified in section 6.1-14. The word "placeholder" seems unnecessary at the beginning of section 8.1. Why not just call it a "data structure"? 8.1. Data structure for Locator Information As defined in Section 6, the SHIM_LOC_*_PREF, SHIM_LOC_*_SEND, and SHIM_LOCLIST_* socket options need to handle one or more locator information. Locator information includes not only the locator itself but also additional information about the locator which is useful for locator management. Figure 4 illustrates [...] Also, for readability, perhaps s/locatior information/locator information block/ ?
Section 5., paragraph 2:
> o Providing locator information to applications. An application
> should be able to obtain information about the locator pair which
> was actually used to send or receive the packet.
DISCUSS: What do you mean by "the packet"? Applications see sockets
out of which they read data. With UDP, you could add a sockopt to get
information about the last packet sent or received, but with TCP, I
don't see how this is supposed to work? Or do you mean the addresses
the shim layer is currently using for the socket?
Section 6.2., paragraph 3:
> Default value is set as 0, which means that the shim sub-layer
> performs identifier/locator adaptation if available.
DISCUSS: I don't think an Informational API document is the place to
specify mandatory default protocol behavior. (If this default behavior
is in the protocol specification, please rephrase this and refer to
the text there.) Note that there are several sections below (6.3,
6.12, etc.) that define "default" protocol behavior, and this issue
occurs whenever the default value for an option turns protocol
behavior on or off (i.e., it doesn't apply in cases where the default
merely affects the behavior of the API itself.)
Section 8.2., paragraph 0:
> 8.2. Path Exploration Parameter
DISCUSS: This section needs to use a RFC2119 MUST whenever it talks
about what do do with parameters from RFC5334. It's not up to an
Informational API document to weaken what is mandated there.
Section 2., paragraph 1: > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in [RFC2119]. This document is very inconsistent with its use of RFC2119 terms. There are many lower-case instances of those terms that I think should be capitalized. There are other cases where wording changes to use RFC2119 terms would clarify things. Section 6., paragraph 0: > 6. Socket Options for Multihoming Shim Sub-layer In many of the subsections under Section 6 that discuss the individual options, the explanatory text doesn't always explicitly state if what is being described is when an option is used with setsockopt vs. with getsockopt. The (unstated) default seems to assume setsockopt. It would be very good to explicitly clarify this, maybe even by explicitly adding subsections for set and get under each.
#1) Why assume only one shim sub-layer is active at a time? Wouldn't the most useful thing for this API to work when WiFi and GSM data are both usable? (Or maybe I'm misunderstanding the text.) In any case, it'd be useful to say why handling both being active is hard or out of scope. #2) I'm curious why there are no requirements to expose security related information, esp IPsec? If it's available wouldn't it be good to provide that?
draft-ietf-speermint-voipthreats
(I am likely to clear this DISCUSS after some discussion with the editors)
4.2. DNSSEC
DNSSEC has not seen wide deployment on the Internet (due to various
reasons which are out of the scope of this document).
Is this statement still true to life, or at least something which should
be preserved in an RFC?
4.12. Minimization of Session Establishment Data
In order to give attackers as few chances as possible for
eavesdropping, session hijacking, and other attacks, SSPs should try
to minimize session establishment data. Unnecessary data exchange
also increases the risk of an implementation vulnerability that could
be exploited by attackers. In addition. unnecessary data exchange
among SSPs can increase the risk of call patterns analysis or
discovery of some SSPs interior topology.
Easier said than done. How exactly this can be achieved?
Can you provide some specific examples?
2.3.1. Threats to SF Confidentiality
o Password cracking - the challenge-response authentication
mechanism of SIP can be attacked with offline dictionary attacks.
Did you mean SIP Digest? If yes, please say so.
With such attacks, an attacker tries to exploit weak passwords
that are used by incautious users.
This document does not seem to consider an attack on one SSP from another,
compromised, SSP. Is this attack explicitly out of scope (then it should state
that) or do any of the countermeasures address such a scenario? To be clear, I
am not pushing to expand the scope of the document, just to clarify it....
The discussion of SRTP and SRTCP in 4.13 does not address which external key
management protocol should be used to set up the initial master key. Is there a
well-defined mechanism for speermint, or is this choice left to the deployment?
SQL injection is mentioned first in section 4. Suggest adding a quick description in section 2 somewhere. Section 4.5 only talks about IPsec and (D)TLS. Have SIP folks given up entirely on message oriented protection?
Overall this document appears to provide a helpful summary of the relevant security issues. Are the suggested countermeasures meant to be exhaustive? (Even I can think of additional countermeasures, such as limiting authentication attempts and obscuring certain error messages to help mitigate directory harvesting attacks.) It would be good to explain whether or not the list is exhaustive. Regarding denial of service attacks, please expand "DoS" on first use and cite RFC 4732. Various other acronyms are not expanded on first use (e.g., SSP). Citations are not provided for several technologies (e.g., ZRTP). The document contains several statements that are dubious (e.g., that scalability requirements lead SSPs to use UDP instead of TCP -- perhaps they need to write better code?) or that might not be true for much longer (e.g., that DNSSEC has not been widely deployed on the Internet -- at least qualify this by saying "at the time of this writing"). As far as I can see, these statements are not material to the recommendations provided in this document, and could be safely removed.
1) The descriptions of several of the threats are incomplete, and as a result
significantly misleading. Rather than try to expand the description to provide
enough detail to not be misleading, I suggest up-leveling the descriptions.
For example, it is not clear in the forged 200 response bullet in section
2.3.2.2
if you are describing an on-path or off-path attacker. Assuming that
you are only
trying to describe off-path, the example doesn't capture the
important differences
on the injected 200 being sent to a proxy or directly to
originating UA, nor does it
note that the element receiving the injected 200
will also see another final response
to the original INVITE (most likely a 487
due to the CANCEL you call out in the
description of the threat).
It should be sufficient to say "Having seen the contents of an INVITE request,
an
eavesdropper can inject a 200 response, affecting the processing of the
transaction
of all proxies between the injection point and the originating UA
and at the
originating UA itself. In the extreme, this can result in a hijacked
call." And
in the countermeasures section, call out that such an attack will
leave signaling
artifacts that will allow it to be detected.
A similar shift in detail would be necessary for many of the other threat
descriptions,
particularly the forged 302 and 404 response threats in section
2.2.2.
2) 2.3.2.1 mentions exploiting broken implementations in its introduction, but
provides
no threats that do so. More detail about what you mean by "guessing"
might help.
3) "SRTP and ZRTP are vulnerable to bid-down attacks, i.e. by selectively
dropping key
exchange protocol packets may result in the establishment of a
non-secure communications."
needs adjustment. It is the keying mechanism, not
SRTP itself that is vulnerable, and
the vulnerability depends greatly on which
mechanism is used. If you are trying to call
out the vulnerability of a
particular mechanism, such as RFC4568, please call it out
explicitly. For ZRTP,
what bid-down attack are you pointing to?
4) The description of Media Hijack in 2.4.2 calls out to a missing Figure 8.
5) Was section 4.8 crafted before RSERPOOL closed? Could it be updated to
reflect the
output of that concluded working group?
6) The first two sentences of 4.13 need adjusting to note that the algorithms
used by
SRTP are negotiated.
7) [refs.voipsataxonomy] should point to a particular version of that taxonomy
draft.
Nits: In section 2.3.2.3, alternation should be alteration In section 4.1 I suggest substituting "document" for "literatures"
#1) I support Tim's discusses. One the 1st one I assume an SSP can be an
attacker based on the call-pattern attacks.
#2) Sec 2.3.2.2, shouldn't this draft address -199 spoofing?
#3) Sec 2.4, is masquerading a concern? That is one UE spoofs another?
draft-ietf-6lowpan-usecases
Some comments from Ari Keränen: One question/comment: 3.6.2. 6LoWPAN Applicability Communication schedules must be set up between master and leaf nodes, and global time synchronization is needed to account for clock drift. Wouldn't time synchronization within the LoWPAN (i.e., not globally) be enough for this use case? And some nits: 3.2.1. A Use Case and its Requirements The second sentence of this paragraph is a bit hard to parse: The physical network topology is changed in case of node failure. On the top part of each pillar, an sink node is placed to collect the sensed data. The sink nodes of each pillar become data gathering point of the LoWPAN hosts at the pillar as local coordinators. Perhaps add something like "and act" before the "as the [...]" part (if that's what it means)? Also: s/an sink/a sink/ 3.3.2. 6LoWPAN Applicability In home network, installation and management must as extremely simple for the user. s/as/be/ Figure 4: "I" in the legend is redundant (there's no "I" in the figure)
An interesting and well written document. I agree with Peter that RFC2119 language does not seem appropriate.
I have a pretty fundamental issue with this document. Many of the described use
cases make requirements on the 6lowpan architecture that I don't think are
realistic, or at least it's very unclear how and if they can be achieved. The
key example is the "support for QoS" requirement that is said to be very
important for many use cases, yet I see no mechanisms in the actual 6lowpan
specs that would support different levels of QoS, or even any text that would
define what "support for QoS" even means in low-powered, maybe-disconnected
networks. Surely it cannot only mean priority queuing, because that's clearly
not sufficient for many of the described uses. Another requirement that is
similarly problematic is "reliable delivery" (which is for some reason included
under security). It's not clear at all to me whether reliable delivery can be
achieved with any sort of timing constraints.
I'm not quite sure how I can make this discuss actionable.
A splendid and useful document that is let down by the Security
Considerations section.
The applicability of 6LowPANs is significantly dependent on suitable
security mechanisms being available. Since 6LowPANs are very vulnerable
to physical layer attacks, it is important to discuss the options and
to identify when the use of these networks is not advisable.
If you can add some beef to that section, I would happily change my
ballot to Yes.
The Security Considerations overlooks a number of very important
issues/challenges raised by the use cases.
First, a number of the use cases are vulnerable to physical threats, including
device theft and simple vandalism. Given the safety issues involved in some use
cases, this would seem to place specific demands for resiliency and
survivability upon the 6lowpan. This issue seems to be overlooked entirely.
Second, while the existing security considerations briefly touch on the need for
encryption, the treatment does not expose the real issues at play. There is a
reference to "lightweight key mechanisms" that deserves expansion - what are
those mechanisms (references please!) The discussion of encryption overlooks a
fundamental problem - the slow processors and limited memory capacity described
in section 1 will be challenged by generally accepted cryptographic algorithms.
However, the safety concerns associated with many use cases precludes deployment
of weak cryptography!
I suspect that authentication will provide a similar set of challenges.
Configuration of strong authentication, with role-based access controls, on the
nodes of even a medium sized lowpan seems problematic. (I don't recall the
specific deployment challenge of provisioning/configuring the security controls
being addressed in the body of the document.)
In 3.5.1, the telematics example has a deployment parameter of "scattered, pre- planned". Somehow these seem in conflict. I share Lars' concern about QoS requirements.
This is a pleasant document. However, given that it discusses use cases and deployment scenarios, I doubt that it needs to use RFC 2119 conformance terms at all. For example, consider the following sentence from Section 3.2: "Some data is not critical for security protection (such as normal room temperature), but event-driven emergency data (such as a fire alarm) MUST be handled in a very critical manner." Well, that's probably the case, but it's really a matter of local service policy, isn't it? Similarly, the assertion in Section 3.4.1 that "Data privacy and security MUST be provided" in healthcare systems is really a matter of either local service policy or applicable legislation (e.g., HIPAA), not RFC 2119 conformance.
Consider clarifying whether the set of dimensions here is intended as a complete list, or is just an important set currently identified.
I support Tim's discussion.
draft-ietf-hip-over-hip
I think it would be useful for the document to talk about what happens when
there's a NAT, and what the interaction with the HIP NAT traversal mechanisms
is. Do you run UDP-ESP-TCP?
The document should state that hiding HIP control packets inside ESP will make it impossible to build NATs or other middleboxes that look inside the HIP packets to do something useful. There used to be a proposal called SPINAT that did this, allowing ESP to go through NATs without UDP encapsulation. SPINAT isn't used anywhere anymore AFAIK, and the one implementation that exists isn't in open source. So this is not a big deal, but for completeness the impact should be noted.
Section 4.2., paragraph 1:
> If the ESP-TCP mode is selected, the host with the larger HIT
> (calculated as defined in Section 6.5 of [RFC5201]) MUST start to
> listen for an incoming TCP connection on the encrypted connection on
> the port it used in the Port field of the transport mode parameter.
DISCUSS: TCP listens on IP address/port number tuples. What's the IP
address to listen on here? (I don't understand what you mean by "on
the encrypted connection".)
INTRODUCTION, paragraph 2: > Host Identity Protocol Signaling Message Transport Modes I think this title sets a record for most number of consecutive nouns. Can we maybe stick a verb and an object in there to improve clarity? Section 4.2., paragraph 4: > Since TCP provides reliable transport, the HIP messages sent over TCP > MUST NOT be retransmitted for the purpose of achieving reliable > transmission. Does this mean that HIP messages may be retransmitted for other purposes? Or it this phrasing inaccurate?
I was surprised to see no discussion of TCP-AO. --- I agree with the Discuss about downgrade attacks. These seem to be particularly open in the mobility/multi-homing case described in Section 6.
The OPS-DIR review performed by David Black pointed to the following problem: The draft is somewhat inconsistent about support for a HIP node policy that requires use of an encrypted transport for HIP signaling. Section 3.3 provides an essential building block, the error signaling mechanism to indicate that an encrypted transport is required and none was proposed. On the other hand, Section 5 is unclear with respect to this class of policy in that it strongly recommends (SHOULD) fallback to a non-encrypted HIP connection but requires (MUST) that "messages that are intended to be sent only encrypted" not be sent unencrypted. If the "messages that are intended to be sent only encrypted" are all HIP messages after the base exchange, these two requirements appear to be in conflict. I suggest adding a short explanation to Section 5 of what would be reasonable vs. unreasonable policy for "messages that are intended to be sent only encrypted", and how to use the Section 3.3 error report when a failed encrypted connection is recovered by attempting to fall back to an unencrypted connection when HIP node policy requires encryption of all signaling after the base exchange. The change was agreed by the document editor and the OPS-DIR reviewer and needs to find its way either in a revised I-D or in a note to the RFC Editor.
Given that bootstrapping of secure communication depends on transmission of the
HIP_TRANSPORT_MODE parameter during HIP base exchange, I'm surprised that the
security considerations do not discuss the possibility of downgrade attacks.
1) It would have helped me had the packet figures from RFC 5201 were added here
(assume I'm getting it right):
The HIP header values for the R1 packet:
IP ( HIP ( [ R1_COUNTER, ]
PUZZLE,
DIFFIE_HELLMAN,
HIP_TRANSFORM,
HOST_ID,
[ ECHO_REQUEST_SIGNED, ]
-> [ HIP_TRANSPORT_MODE,]
HIP_SIGNATURE_2 )
<, ECHO_REQUEST_UNSIGNED >i)
Not sure if it's exactly in the right place. This would make it clear that the
transport mode is signed. Same for I2:
IP ( HIP ( [R1_COUNTER,]
SOLUTION,
DIFFIE_HELLMAN,
HIP_TRANSFORM,
ENCRYPTED { HOST_ID } or HOST_ID,
-> [ HIP_TRANSPORT_MODE, ]
[ ECHO_RESPONSE_SIGNED ,]
HMAC,
HIP_SIGNATURE
<, ECHO_RESPONSE_UNSIGNED>i ) )
2) Sec 4.2: Difficult to parse the sentence Lars has a discuss on.
3) Why SHOULD the TCP originator use the source port they said they'd use? I
could understand a MUST or with NATs a MAY but can't figure why SHOULD?
draft-ietf-hip-cert
Agree with Peter's Discuss. The update to 5201 should be noted in the document header and the Abstarct. --- Section 2 It MAY either carry SPKI certificates or X.509.v3 certificates. I think lower case "may" is more appropriate. Unless you mean... It MUST carry either SPKI certificates or X.509.v3 certificates.
3. X.509.v3 Certificate Object and Host Identities
When using X.509.v3 certificates to transmit information related to
HIP hosts, HITs MAY be enclosed within the certificates. HITs can
represent an issuer, a subject, or both. In X.509.v3 HITs are
represented as issuer or subject alternative name extensions as
defined in [RFC5280].
Using which type(s)? Examples below show IP Address, but this is not stated
normatively.
If only the HIT of the host is presented as
either the issuer or the subject the respective HIT MUST be placed
into the respective entity's DN's Common Name (CN) section in a colon
delimited presentation format defined in [RFC5952]. Inclusion of CN
is not necessary if DN contains any other naming information. It is
RECOMMENDED to use the FQDN/NAI
How are these going to be represented in DNs? Are you assuming CN=<FQDN>
or something else? What about NAI?
from the hosts HOST_ID parameter in
the DN if one exists. The full HIs are presented in the public key
entries of X.509.v3 certificates.
In this scenario, it is RECOMMENDED that the HIP peers have and use
some mechanism of defining trusted root CAs for the purpose of
establishing HIP communications. Furthermore it is recommended that
the HIP peers have and use some mechanism of checking peer
certificate validity for revocation, signature, minimum cryptographic
strength, etc., up to the trusted root CA.
The whole paragraph: this looks way too informative and way too weak.
Maybe point to RFC 5280?
7. IANA Considerations
The CERT parameter has 8-bit unsigned integer field for different
certificate types, for which IANA is to create and maintain a new
sub-registry entitled "HIP certificate types" under the "Host
Identity Protocol (HIP) Parameters". Initial values for the
Certificate type registry are given in Section 2.
What is the IANA registration procedure for this registry?
Section 7 states:
This document defines the CERT parameter for the Host Identity
Protocol [RFC5201]. This parameter is defined in Section 2 with type
768. The parameter type number is also defined in [RFC5201].
Therefore does this document need to say that it updates RFC 5201?
Please spell out acronyms on first use (I1, HI, HIT, FQDN, NAI, etc.). A reference to RFC 4282 might be appropriate with respect to NAI. References to various DNS-related specifications might be appropriate with respect to FQDN (also please clarify if internationalized domain names are allowed).
#1) I was expecting a profile of RFC 5280 to identify which extensions
MUST/SHOULD be present in X.509 certificates. Shouldn't this draft specify a
profile and indicate things like:
- The IAN and SAN extensions MUST be present? Assuming yes: which GeneralName
form MUST be used?
- Are there any HIP specific EKUs?
- What algorithms (signature and hash) MUST be used to sign the
certificates/CRLs (just pointing to 5201bis)?
#2) Section 2 includes the following:
It MAY either carry SPKI certificates or X.509.v3
certificates.
Are OpenPGP certificates prohibited? Are you just trying to say that this
document specifies the semantics for carrying SPKI or X.509.v3 certificates? It
sounds like the registry is limited to only these two types.
#3) X.690 is normative because you require it be supported.
#1) <nit picking alert>r/Digital certificates bind a piece of
information/Digital certificates bind a pieces of information<nit picking alert>
#2) Section 2 3rd para: "not recommended" is used but should it be "NOT
RECOMMENDED". It is 2119 language, but you'd need to update the Sec 1.1 as per
the following errata: http://www.rfc-
editor.org/errata_search.php?rfc=2119&eid=499.
#3) Cert Type Number: Should probably reserve value 0.
#4) It may be useful to say that a receiver SHOULD validate the certificate
signature against the octets received in case the sender/CA sent some bad DER
that doesn't re-encode identically. This has happened in the past.
#5) Checking a URL, or LDAP entry creates a potential DoS. That should be
mentioned in the security considerations.
#6) Should this be RECOMMENDED:
Furthermore it is recommended that
the HIP peers have and use some mechanism of checking peer
certificate validity for revocation, signature, minimum cryptographic
strength, etc., up to the trusted root CA.
Also, RFC 5280 indicates that revocation checking is optional. Was upping this
to RECOMMENDED done on purpose?
#7) Is there no way for a responder to signal trust anchor information to an
initiator? That can be handy, but if the WG didn't want it then fine.
#8) IANA Considerations: Do you need to specify how the registry is updated
(e.g., specification required, IETF consensus)?
#9) Should point to 5280 for security considerations X.509v3 certificates and
2693 for SPKI certificate security considerations.
#10) Probably should just the same reference for X.690 as RFC 5280 uses:
[X.690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002,
Information technology - ASN.1 encoding rules:
Specification of Basic Encoding Rules (BER), Canonical
Encoding Rules (CER) and Distinguished Encoding Rules
(DER).
#11) Should expand HIT, HI, NAI, and FQDN.
draft-mraihi-mutual-oath-hotp-variants
I found the list of requirements in Section 3 helpful in understanding why the algorithm is built the way it is. But I also found the requirements a little lacking in motives. Would it be possible to add a single sentence to each requirement to say *why* the requirement holds? --- I think you need to add a reference to the definition of the BNF you are using.
3. Algorithm Requirements
R1 - The algorithm MUST support asynchronous challenge-response based
authentication.
Can you please explain in more details what this means?
5.1. DataInput Parameters
o T is an 8-byte unsigned integer in big endian (i.e. network byte
order) representing the number of time-steps(seconds, minutes,
hours or days depending on the specified granularity) since
midnight UTC of January 1, 1970.
Where is the granularity is specified?
More specificatlly, if the OCRA
computation includes a timestamp T, you SHOULD first convert your
current local time to UTC time (text form);
Is use of the "text form" really a SHOULD? This looks like an implementation
detail.
I think the use of a RFC 2119 keyword is incorrect here.
you can then derive
the UTC time in the proper format (i.e. seconds, minutes, hours or
days elapsed from Epoch time); the size of the time-step is
defined in the OCRASuite string
5.2. CryptoFunction
The default CryptoFunction is HOTP-SHA1-6, i.e. the default mode of
computation for OCRA is HOTP with the default 6-digit dynamic
truncation and a combination of DataInput values as the message to
compute the HMAC-SHA1 digest.
What is "digit" in this case? A decimal digit? A hex digit?
6. The OCRASuite
An OCRASuite value is a text string that captures one mode of
operation for the OCRA algorithm, completely specifying the various
options for that computation. An OCRASuite value is represented as
follows:
Algorithm:CryptoFunction:DataInput
It is not clear to me if this is supposed to represent a pseudo-ABNF or
something else.
Is this saying that 3 strings are separated by ":" characters?
6.1. Algorithm
Description: Indicates the version of OCRA algorithm.
Values: OCRA-v where v represents the version number (e.g. 1, 2
etc.). This document specifies version 1 of the OCRA algorithm.
Are there any rules about backward compatibility between higher versions and
lower versions?
In Section 8.2:
IC8 - We recommend that implementations MAY use the session
information, S as an additional input in the computation. For
example, S could be the session identifier from the TLS session.
This will mitigate against certain types of man-in-the-middle
attacks. However, this will introduce the additional dependency that
first of all the prover needs to have access to the session
identifier to compute the response and the verifier will need access
to the session identifier to verify the response.
Should this paragraph point to RFC 5056 and RFC 5929?
Appendix A. Reference Implementation
import java.lang.reflect.UndeclaredThrowableException;
import java.security.GeneralSecurityException;
import javax.crypto.Mac;
import javax.crypto.spec.SecretKeySpec;
import java.math.BigInteger;
/**
* This an example implementation of the OATH OCRA algorithm.
* Visit www.openauthentication.org for more information.
*
* @author Johan Rydell, PortWise
*/
Is the license for this code compatible with IETF rules?
5.1. DataInput Parameters
o P is a hash (SHA1, SHA256 and SHA512 are supported) value of PIN/
This is missing some references.
password that is known to all parties during the execution of the
algorithm; the length of P will depend on the hash function that
is used
o S is an UTF-8 encoded string of length upto 512 bytes that
A normative reference for UTF-8 is missing here.
contains information about the current session; the length of S is
defined in the OCRASuite string
In Section 8.2:
IC6 - All the communications SHOULD take place over a secure channel
e.g. SSL/TLS, IPsec connections.
Informative reference to TLS is needed here.
IC9 - In the signature mode, whenever the counter or time (defined as
optional elements) are not used in the computation, there might be a
risk of replay attack and the implementers should carefully consider
this issue in the light of their specific application requirements
and security guidelines.
Is any advice about time synchronization needed here?
The server SHOULD also provide whenever
possible a mean for the client (if able) to verify the validity of
the signature challenge.
This is a clear and well-written document. The OPS-DIR review performed by David Black made one comment, which refers to a clarification aspect. It is not a blocking issue, but addressing it would be useful: I do have one suggestion for improved clarity. The first sentence in the introduction states that a primary motivation for these algorithms as support for "users who do not want to maintain a synchronized authentication system." In contrast, the C component of DataInput in Section 5.1 is a counter that "MUST be synchronized between all parties." The reason that these two statements are not in conflict is the counter is optional for all of the algorithm modes defined in the draft. A statement to that effect should be added to Section 5.1 - IMHO, assuming that the optional nature of the counter will be inferred from the omission of the word "mandatory" is insufficient.
draft-baker-ietf-core
None of the comments below taken alone is discuss-worthy, but I do think at least several of them should really be addressed. Section 2.1.2., paragraph 3: > For example, TCP will > reduce rate to avoid loss, while DCCP accepts some level of loss if > necessary to maintain timeliness. TCP doesn't really reduce its rate to avoid loss - it uses loss as an indication for congestion, and basic congestion control principles mandate a rate reduction. DCCP does the same - the difference is that DCCP will not bother to retransmit lost data while TCP will. Section 3.2.2.3., paragraph 3: > In that research, the IETF imposed guidelines [RFC2357] on the > research community regarding what was desirable. Important results > from that research include a number of papers and several proprietary > protocols including some that have been used in support of business > operations. RFCs in the area include The Use of Forward Error > Correction (FEC) in Reliable Multicast [RFC3453], the Negative- > acknowledgment (NACK)-Oriented Reliable Multicast (NORM) Protocol > [RFC5740], and the Selectively Reliable Multicast Protocol (SRMP) > [RFC4410]. These are considered experimental. This section has outdated information. NORM is now PS (RFC 5401), and FLUTE is almost there (IETF LC of draft-ietf-rmt-flute-revised is imminent). Reliable multicast is not experimental anymore. Section 3.3.2., paragraph 2: > it delivers data to its peer and provides acknowledgement to the > sender, or it dies trying. It has extensions for Congestion Control > [RFC5681] and Explicit Congestion Notification [RFC3168]. As well as many other extensions - it may be useful to cite RFC 4614 here. Section 3.3.2., paragraph 3: > For message-stream interfaces, we generally use the ISO > Transport Service on TCP [RFC1006][RFC2126] in the application. Who is "we"? Is anyone really using RFC1006 and RFC2126? Section 3.3.2., paragraph 5: > Finally, note that TCP has been the subject of ongoing research and > development since it was written. The End to End research group has > published a Roadmap for TCP Specification Documents [RFC4614] to > capture this history, to guide TCP implementors, and provide context > for TCP researchers. RFC 4614 did not come out of end-to-end, it was a WG document in TCPM. And while it does capture some of the history and research aspects, the motivation was very much to be a "start reading here" document for implementors, similar in spirit to this I-D. Section 3.6.2., paragraph 8: > The Constrained Application Protocol (CoAP) [I-D.ietf-core-coap] is > being developed in IETF with these goals in mind. I'm surprised to see that COAP is only mentioned under resource discovery. While that's one aspect of it, the broader aspect is as an application/transport protocol for constraint environments. IMO it would make more sense to discuss COAP under Section 3.3 or 3.3.1. Section 4., paragraph 0: > 4. A simplified view of the business architecture At least to my mind, it would be a bit more logical to see this section merged into Section 2 or following it. (Also, it'd be nice to replace domain names and IP addresses in this section with ones from the "example" spaces.) Section 5., paragraph 1: > This memo asks the IANA for no new parameters. Although this document makes no requests from IANA, I wonder if the smartgrid guys know about the role that IANA plays in the standardization and administration of the IPS. Is there an IANA overview document that you could cite here for them to read? Section 8., paragraph 0: > 8. References Is there a logic to the split between normative and informative references? Appendix A., paragraph 1: > This appendix provides a worked example of the use of the Internet > Protocol Suite in a network such as the Smart Grid's Advanced > Metering Infrastructure (AMI). There are several possible models. I don't think this example is worked out enough to illustrate how the IPS can be applied here. There's a little bit of text about layer 3, and nothing at all about higher layers. I wonder if this material would be better split off into a standalone document for further development. --- Section 2.2., paragraph 1: > solutions to many Internet security problems have already exist. Nit: s/have// Section 2.2.1., paragraph 3: > For wirless transmission technologies eavesdropping on the Nit: s/wirless/wireless/ Section 3.2.3.1., paragraph 1: > Autoconfiguation enables various different models of network Nit: s/Autoconfiguation/Autoconfiguration/ Section 802.11, paragraph 0: > networks between various sensors in the home (e.g., betweeen the Nit: s/betweeen/between/
Fine work. I should have liked to see some forward reference to the Appendix from early in the document since (I assume) the readers will find the Appendix quite useful and (although it is mentioned in the ToC) there is no other hint that it is there.
Two actionable discusses, one discuss-discuss:
Actionable 1: Please add a brief section 3.1.5 Key Management Infrastructures to
cover PKI (PKIX) and Kerberos.
These are a very important building block in the
security toolbox. I would suggest mentioning the DANE work in this
section as
well.
Actionable 2: Please add a brief section 3.1.6 secure shell. This is another
and widely used key building block.
Discuss-discuss: I would have expected to see some discussion of SRTP and SRTCP,
but neither RTP nor RTCP
is mentioned. Was there a specific decision not to
include these protocols? If so, excluding SRTP and SRTCP
makes perfect sense.
technical comments:
2.2
OLD
While it is popular to complain about the security of the Internet,
solutions to many popular Internet security problems have already exist.
NEW
While it is popular to complain about the security of the Internet,
it is important to distinguish between attacks on protocols and
attacks on user (e.g., phishing). Attacks on users are largely independent
of protocol details, reflecting interface design issues or user education
problems, and are out of scope for this document. Security problems with
Internet protocols are in scope, of course, and can often be mitigated
using existing security features already specified for the protocol, or
by leveraging the security services offered by other IETF protocols.
2.2.2
Append to the paragraph beginning "A number of mechanisms":
Another mechanism, specifically targeting the reset attack cited above,
provides authentication services in TCP itself to ensure that fake resets
are rejected.
3.1
OLD
It is important to highlight that in addition to the mentioned
security tools every protocol often comes with additional, often
unique security considerations that are very unique to the specific
domain that protocol operates in.
NEW
It is important to highlight that in addition to the mentioned
security tools every protocol often comes with additional, often
unique security considerations that are very unique to the specific
domain that protocol operates in. Many protocols include features
specifically designed to mitigate these protocol-specific risks. In
other cases, the security considerations will identify security-relevant
services that are required from other network layers to achieve
appropriate levels of security.
3.1.2
[Note: The TLS section talks about negotiating parameters as suites, but the
IKE section is silent. The following suggestion would be more complete
and provide some parallelism.}
OLD
For the former step the Internet Key Exchange protocol version 2
(IKEv2 [RFC5996]) is the most recent edition of the standardized
protocol.
NEW
For the former step, the Internet Key Exchange protocol version 2
(IKEv2 [RFC5996]) is the most recent edition of the standardized
protocol. IKE negotiates each of the cryptographic algorithms that
will be used to protect the data independently, somewhat like
selecting items a la carte.
3.1.2 penultimate paragraph:
Please append:
Since ESP can also provide authenctication services, most recent
protocol development making use of IPsec only specify use of ESP
and do not use AH.
3.1.3
Adding a reference to RFC 6090 in 3.1.3 would be good, e.g.
"The basic cryptogaphic mechanims for ECC have been documented
in RFC 6090." That could be added to the end of the 2nd last
para in 3.1.3.
3.1.4
CMS paragraph: Please append the following:
CMS has been leveraged to supply security services in a variety of
protocols, including secure email [RFC5751], key management [RFC5958]
and [RFC6031], and firmware updates [RFC4108].
Digitally signed XML paragraph: Please append the following:
Digitally signed XML is a good choice where applications natively
support XML encoded data.
Section 3.7
What about email, ftp, http? Do these have any application in this space?
4. (current page 36)
Firewalls are also common on end-hosts as well. This may be worth a mention
in this section.
----
editorial comments:
2.1.3.2
s/can recursively subdivided/can be recursively subdivided/
2.2
s/takes security serious/takes security seriously/
s/provides recommendations how/provides recommendations on how/
2.2.2
s/are round/exist/
3. (last sentence)
s/such analyzes/such analysis/
3.1
s/we outline of/outline a/
3.1.1
first sentence:
s/The term/While the term/
second Para:
s/prior to access a/prior to accessing a/
Before I vote YES on this document I would suggest fixing a few obvious
editorial problems. Fixes should be easy.
1. Section 2.1.1 - please do not refer to [RFC1157] when speaking about SNMP.
This one is Historical. Best would be to refer to [RFC3411] and remove the
reference to 1157
2. Section 2.1.3.2 - IEEE 802.16 is not a local wireless network - they define
themselves as metropolitan wireless network
3. Section 2.3.2 - remove the words 'and is a polled architecture' when refering
to SNMP. This is not completely accurate and conflicts with what is written
later in Section 3.5.1
1. [SmartGrid] - I am unconfortable to providing wikipedia references - not because I do not trust the principle of shared wisdom, but because they are unstable to my taste even for Informational References. If there is really nothing else around (even not from NIST?) I wouls suggest that at least we provide together with the reference a date when the quote was extracted from the wikipedia article 2. It is not clear to me why from all applications possible section 3.7 selects exactly SIP and calendaring. Are these applications considered candidates to run on the Smart Grid more than other applications?
The introduction states:
o Section 3 outlines the set of protocols that will be useful in
Smart Grid deployment.
Is this statement (*the* set of protocols) meant to imply that no other
protocols might be useful in smart grid deployments? (Naturally, I know of
several companies that have deployed XMPP quite widely for smart grid
deployments, but I'm sure there are other protocols one could add to the set, as
well.)
Regarding Section 3.7.2, is calendaring really of strong interest or use in
smart grid deployments?
1) Would it be possible (and would it preserve the intended meaning) to say
"identifies the key infrastructure protocols of the Internet Protocol Suite"
instead of just "the key protocols" in the introduction?
2) Echoing 1) above, would text along these lines be acceptable for the
introduction to section 3.7?
"There are many applications that rely on the IP
infrastructure, but are not properly thought of as part of the IP infrastructure
itself. These applications may be useful in the context of the Smart Grid. The
choices made when constructing a profile of the Internet Profile Suite may
impact how such applications could be used. Two such protocols (not by any means
an exhaustive list) are discussed here."
3) The description of the impact of NATs on SIP needs tweaking. As it is, it
implies the only way to work through NATs is for the NAT itself to be an ALG,
modifying signaling packets, but the endpoints themselves can work (using tools
like STUN) through SIP unaware NATs. SIP messaging itself does have an issue
with NATs (see RFC5626, or draft-ietf-sipping-nat-scenarios). I suggest just
noting that choosing to introduce NATs as part of the profile will increase the
complexity of deploying SIP applications and point to 5626 for a discussion of
the details.
#1) Sec 2.2.2: How about we use CIA, Confidentiality, Integrity, and
Availability (the classic model), and throw in Authenticity:
At the network, transport, and application layers it is common to demand a few
basic security requirements, commonly referred to as CIA (Confidentiality,
Integrity, and Availability):
1. Confidentiality: Protect the transmitted data from unauthorized disclosure
(i.e., keep eavesdroppers from learning what was transmitted). For
example, for trust in e-commerce applications credit card transactions are
exchanged encrypted between the Web browser and a Web server.
2. Integrity: Protect against unauthorized changes to exchanges,
including both intentional change or destruction and accidental
change or loss, by ensuring that changes to exchanges are detectable.
It has two parts: one for the data and one for the peers.
- Peers need to verify that information that appears to be from a
trusted peer is in fact from that peer. This is typically called
'data origin authentication'.
- Peers need to validate that the content of the data exchanged
is unmodified. The term typically used for this property is data
integrity.
To this we add authenticity, which requires that the communicating peers prove
that they are in fact who they say they are. One peer can prove to the other
who they are (i.e., one-way authentication), but in general two-way (or mutual)
authentication is best. Mutual authentication is performed at a minimum by
using a) something the user knows and the b) something the user has. Single-
factor authentication assumes the user knows their username and they have a
secret (think password). Two-factor authentication assumes the user knows their
password (typically to unlock a key stored on the token) and the user has a
token (think smartcard). Multi-factor authentication adds a c) the user is
(e.g., biometrics).
#2) Section 2.2.2: Many times we say people say use TLS - we're done right. I
think we should say something about hop-by-hop security vs end-to-end security.
#3) How do we see OAUTH playing in this space? Should Kerberos be discussed?
#4) Should we talk about TCP security (i.e., TCP-AO)?
#5) Section 3.2 talks about routing. Should we discuss routing security as
well?
#1) Politics layer is missing from Figure 1 ;) #2) <nit alert>r/"host./"host."</nit alert> #3) Could we point to SNMPv3 instead of v1? (i.e., something that's not historic) #4) Is it worth mention HIP at all or the concept of splitting the identifier and locator? It's experimental so maybe not. #5) Is it worth adding an informative reference to https://datatracker.ietf.org/doc/draft-ietf-tcpm-tcp-security/ in 2.2.2 where it talks about TCP attacks/counter measures? Also maybe pointing to https://datatracker.ietf.org/doc/draft-ietf-opsec-ip-security/ for IP attacks/counter measures would be helpful. #6) Section 3.1.1: can we also add EAP-TLS: For access to remote networks, such as enterprise networks, the ability to utilize EAP within IKEv2 [RFC5996] and within TLS [RFC5216] have also been developed. #7) While the Suite B IPsec profiles are near and dear to my heart, I'm not sure they need to be included in Sec 3.1.2. #8) Sec 3.1.3: It's probably worth noting that TLS supports hop-by-hop security and depending on the architecture this might not be end-to-end (i.e., TLS isn't one size fits all). #9) Sec 3.1.4: for truth in advertising: The CMS can support a variety of architectures for key management included: certificate-based key management, such as the one defined by the PKIX (Public Key Infrastructure using X.509) working group [RFC5280], or symmetric key management. #10) Sec 3.1.4: Should also add that a variety of algorithms are supported: CMS supports a number of algorithms: RSA, DSA, DH, ECDSA, and ECDH as well as the SHA family of algorithms. #11) Sections 3.1.2-3.1.4: When renaming 3.1.4 to "Application Security" makes me think that 3.1.2 should be called "Network Security" and 3.1.3 should be called "Transport Security". Then put SSH in 3.1.3 (maybe no need for a new 3.1.6 as Tim suggests). Could have two subsections. #12) I think this needs to be updated: Note that since IPv4 free pool (the pool of available, unallocated IPv4 addresses) is almost exhausted,
draft-josefsson-rc4-test-vectors