IESG Narrative Minutes
Narrative Minutes of the IESG Teleconference on 2008-04-24.
Narrative scribe: John Leslie
Corrections from Russ, Tim
1133 EDT telechat started
Amy: with Cindy Morgan, who will moderate today
1 Administrivia
- Roll Call
- Bash the Agenda
Cindy: Add?
- Rearrange Ron's chartering if he shows up
- Magnus:
Tools question, linking discuss to issues
- Approval of the Minutes of the past telechat
Apr 10 approved, will post
Narrative. will post
- Review of Action Items from last Telechat
Cindy: 3 for Cullen
Cullen: 3rd in progress
Cindy: Chris, TMDA
Chris: finished as of last telechat (minutes OK)
2 Protocol Actions
2.1 WG submission
2.1.1 - New Items
- OSPF Multi-Area Adjacency (Proposed Standard)
draft-ietf-ospf-multi-area-adj-08.txt
Token: David Ward
Discuss:
Telechat:
Cindy: no discusses, approved
- OSPFv3 Graceful Restart (Proposed Standard)
draft-ietf-ospf-ospfv3-graceful-restart-07.txt
Token: David Ward
Discuss:
- Russ Housley: In her SecDir Review, Hilarie Orman pointed out that the message described in this document seems to give attackers a new method obscuring network configuration changes. If it is possible to send bogus messages, the adjacency of a dead router could be preserved indefinitely.
In response, Acee Lindem indicated that this attack is much more difficult than the obvious replay of a normal OSPFv3 hello packets to keep the adjacency up. Since hello packets are sent more predictably and knowledge of the key is not required, the risk added by OSPFv3 graceful restart is insignificant.
I would like to see this information added to the Security Considerations.
- Chris Newman: The IANA considerations section does not properly name the registry that is used by this document. While it appears IANA was able to discern the correct registry as the "OSPFv3 LSA Function Codes" sub-registry of the "Open Shortest Path First v3 (OSPFv3) Parameters" registry, the document should actually include the precise names so readers of the document without in-depth knowledge of IANA can find the registry.
Telechat:
Dave: ask Russ
Russ: add a sentence or two, then fine
Cindy: AD followup
- NFS Direct Data Placement (Proposed Standard)
draft-ietf-nfsv4-nfsdirect-08.txt
Note: Document Shepherd: Spencer Shepler (spencer.shepler@sun.com)
Token: Lars Eggert
Discuss:
Telechat:
Cindy positions pending from folks on telechat
Lisa: no position
Pasi: no position
Cullen: no position
Cindy: any objections, approved
- Remote Direct Memory Access Transport for Remote Procedure Call (Proposed Standard)
draft-ietf-nfsv4-rpcrdma-08.txt
Note: Document Shepherd: Spencer Shepler (spencer.shepler@sun.com)
Token: Lars Eggert
Discuss:
- Lisa Dusseault:
I am getting an early DISCUSS in to see if some answers can clear this up quickly. I hope to revise this DISCUSS even before the call as I understand it better.
Is the applicability of RDMA, RPC and NFS as described in this document limited to trusted situations where an administrator explicitly sets up a data transfer or a synchronization relationship between two servers?
I can see this being useful in contexts where you basically want superuser access to a file system.
If the applicability is not limited, how is this appropriate for Internet or end-user usage, especially considering the limited authentication mechanisms and lack of information on mapping to NFS ACEs?
Telechat:
Cindy: positions pending from folks on telechat
Pasi: no position
Cullen: no position
Chris: not at this time
Lisa: expect to require revised ID
- Hierarchical Mobile IPv6 Mobility Management (HMIPv6) (Proposed Standard)
draft-ietf-mipshop-4140bis-02.txt
Note: Document shepherd is Vijay Devarapalli
Token: Jari Arkko
Discuss:
- Lars Eggert: Appendix A. Appendix A - Fast Mobile IPv6 Handoers and HMIPv6
DISCUSS: Has the experiment with RFC4140 covered Fast Hierarchical MIPv6 at all? There are zero technical changes between this appendix in RFC4140 and this document, and with the text below referring to SEAMOBY as if it was still around, I wonder if this appendix isn't outdated and should simply be removed for PS.
Appendix B., paragraph 5:
RFC 4140 was implemented and interop tested by at least two different organisations. A test suite including test cases for RFC 4140 was also developed by Ericsson and run against both implementations. No major issues were found. The scalability of Dynamic MAP discovery defined in RFC 4140 was seen as inappripriate for large scale deployments and prone to loops. It was removed from this specification.
DISCUSS-DISCUSS: This rationale for going from Experimental to PS is weak. OK, so two implementations interoperated, some minor things were removed, but the open question is whether the protocol actually works as advertised and is useful?Comment [2008-04-19]:
Section 14., paragraph 0:
14. References
Document contains a six or so unused references, suggest to remove them.
Section 14.2., paragraph 3:
[RFC4068] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068, July 2005.
I think this should cite draft-ietf-mipshop-fmipv6-rfc4068bis.
- David Ward:
In section 7.1 there is a mention of options (e.g. preference) that are associated with MAP IP addrs but, there is a very limited encoding (e.g. no flags, or other attributes) in the MAP option. In addition, the definition of a Dist is limited to 4 bits. Is that enough? Is it reasonable to assume that no semantics are to be associated with distance?
Later, in the selection algorithm for distributed MAPs (9.1) it appears that DIST and PREF are directly comparable. Although DIST is used as a sorting (akin to hop count although earlier not required), the pref is then used to bias selection. The problem with no strict semantics for DIST to be hop count (e.g. it could be used as inverse hop count) then you'd get a non-optimal selection algorithm. In addition, the PREF variable alone only allows for a very weak application of operational policy (since all this has to be hand configured - no dynamic specified). Given what we know about policy selection requirements from other protocols, something should be mentioned what the RESV space is for or allow at this time greater operational options (via more attrs, flags, etc).
Bottomline, the definition of the options (DIST, PREF) appear to not have strict enough semantics to meet the requirements of the default selection algorithm.
Next, the section on failure detection and recovery from MAP failures is unfortunately not useful because it describes possible failure detection methods but, nothing to be standardized. Either something has to be specified, referenced or the section has to be removed as an implementor has nothing to specified to detect failures.
- Russ Housley: Section 11 says: Confidentiality may be needed for payload traffic, but is not required for binding updates to the MAP.
Under what circumstances is confidentiality desired? When it is desired, is ESP used to provide it?
Comment [2008-04-24]: s/Figure 1: Figure 1:/Figure 1:/
- Tim Polk: In general, I thought this was a good document. However, there are some problems that need to be remedied before publication. Most of the issues involve the Security Considerations section, but some changes to the body might also be helfpul. (This is in part a follow-on to Lakshminath Dondeti's secdir review and highlights the issues I consider blocking.)
(1) The document introduces the Mobility Anchor Point (MAP) into the mobile IPv6 architecture, but the requirements/assumptions regarding the relationship between the mobile node and the MAP are not clear enough. These assumptions/requirements have a number of implications for the protocols that should be stated. In particular, there is an implication that the trust relationship is so limited that authentication as a group member is generally sufficient. For example, a MAP may authenticate a mobile node based on a certificate issued by a known CA, rather than the specific identity in the certificate. Similarly, the mobile node may authenticate the MAP based on a cert from a known CA, even though the specific MAP was previously unknown. (Examples from 11.1) I believe this is okay, based on my understanding of the requirements, but I would feel more confident if the trust relationship was fleshed somewhere.
Note that this is confused somewhat by the discussion of "security relationship" between the mobile node and the MAP in section 11. "mutual authentication, integrity protection and protection against replay attack" are necessary features, not a relationship.
(2) Authentication and authorization are conceptually related but they are different. Authentication is generally the precursor, where we determine another party's identity, and authorization follows based on that identitty. Just because a party's identity has been authenticated does not mean they are authorized to access anything. The examples cited above blur the lines between these steps. Hopefully, this will be addressed as a side effect of addressing (1), but please revise with an eye towards clarity on authentication vs. authorization.
(3) The security considerations section focuses on the expected deployment architecture, but several alternatives are specified in the document. Tehse should be addressed in teh security considerations as well - either to describe differences in teh security considerations or to state that they are unchanged.
For example, It is noted in the introduction that the mobile node can operate in a nomadic manner (no permanent home address). Section 6.5 notes that the RCoA address can be used as the source address without a Home Address option. In these kinds of cases, are there additional constraints or limitations imposed on the trust relationship between the MAP and the mobile node?
- Mark Townsley: The introduction describes that without the mipshop optimization, MNs have on average 1.5 signaling round-trips when the node moves... Then makes a fairly wild leap of conclusion that:
These round trip delays will disrupt active connections every time a handoff to a new AR is performed. Eliminating this additional delay element from the time-critical handover period will significantly improve the performance of Mobile IPv6.
What connections are being disrupted for each and every AR? Also, I see no analysis here that shows that there will be a significant performance improvement to the Mobile IPv6 user.
There is language in this document stating the optional nature of this feature, but if the above claims are true then I cannot see how this could be optional. So, the document is rather inconsistent here.
I think that probably the right thing to do is to tone down some of the claims of what this optimization does and does not do.
- Magnus Westerlund: The tunneling between the MAP and the mobile node introduces an extra layer of tunneling that may effect (will unless the path between the MN and the MAP has a MTU that is at least tunnel overhead larger than the real MTU bottelnek) the path MTU between the CN and the MN. There needs to be some discussion of this impact on the traffic between the CN and the MN. Especially as this is dynamic and can change due to the choices of the MN or changing the used MAP.
Comment [2008-04-24]: I found one acronym in Section 6.1 that isn't explained nor used again: DAD
Telechat:
- Ross: shouldn't hold to higher standard
- Cullen: can be harm, we get pushback "already a standard"
- Jari: were I rechartering, would be different
- Russ: I cleared on RFC-ed note
- Jari: no research to support claim of significance (Mark's discuss)
- Mark: don't claim too much
- Jari: Dave's points
- Dave: Main point re distance prefs, underspecified and overused, if not needed now, say so, semantics need work
- Jari: Hope to cut things out
- Dave: trying for sort and pref, don't need both; on failure detection, doesn't say how-to, too much hand-waving
- Jari: might take it all out, already watered down from a previous draft
- Magnus: my usual tunneling issue
- Datagram Transport Layer Security (DTLS) over the Datagram Congestion Control Protocol (DCCP) (Proposed Standard)
draft-ietf-dccp-dtls-06.txt
Note: Document Shepherd: Gorry Fairhurst (gorry@erg.abdn.ac.uk) - DCCP WG Chair
Token: Lars Eggert
Discuss:
Telechat:
Cindy: no positions pending (among callers)
Russ: approve pending Lars review of comments
- The OSPF Opaque LSA Option (Proposed Standard)
draft-ietf-ospf-rfc2370bis-02.txt
Token: David Ward
Discuss:
- Pasi Eronen: RFC 2370 said "the O-bit is not set in packets other than Database Description packets"; this sentence has been changed to "the O-bit SHOULD NOT be set and SHOULD be ignored when received in packets other than Database Description packets." SHOULD implies that there may exist "valid reasons in particular circumstances" to ignore this; the document should briefly explain what that reason could be, if the situation has indeed changed from RFC 2370 times.
- Chris Newman: The IANA considerations section requires review of standards track OSPF extensions by a designated expert once the OSPF WG has disbanded. I would like to understand how this procedure will work and how we can be sure the requirement is not lost between now and when the OSPF WG is disbanded.
In addition, the IANA considerations section refers to IANA registries without giving the precise name of the registry. Please fix that.
Telechat:
- Dave: Pasi commented re rewrite to use IETF terms, the right thing will happen by ignoring
- Pasi: why not use MUST?
- Dave: cases we might not want to preclude
- Pasi: this leaves it unspecified
- Dave: unknown option bits ignored in 2328
- Pasi: say no known users
- Dave: Chris, can we just do RFC-editor note
- Chris: we could delete mention of Designated Expert (AD would handle)
- Dave: willing to delete
- Michelle: will there be designated registration procedures
- Chris: was additional requirement, would be just STDs action when we delete
- Dave: legacy issue, editor note to remove designated expert
2.1.2 Returning Items
2.2 Individual Submissions
2.2.1 New Items
- A Registry for SMTP Enhanced Mail System Status Codes (BCP)
draft-hansen-4468upd-mailesc-registry-04.txt
Note: Harald Alvestrand is document shepherd
Token: Chris Newman
Discuss:
- Cullen Jennings:
The early registration procedures don't work for a document that is not a WG document. I think the easiest way to fix this would be just to use AD Approval for these.
- Russ Housley:IANA has questions:
Extended code X.7.8 is defined in both RFC4468 and RFC4954. Which one should go into the registry? It APPEARS you want the RFC4954 version and NOT the RFC4468 version?
Also, IANA usually calls it a "Reference", not "Defined". The registry entries have been updated appropriately but the document should get updated to match.
Who will fill in the "not given" information?
- Magnus Westerlund: Section 2.1: Change Controller: "This will be "IESG" in the case of IETF-produced documents."
>br>Shouldn't this actually be IETF? If I compare this to media types that also have a change controller field, we are generally very hesitant to specify anything else than IETF. After all IETF means that we need consensus on the change which will be judged by IESG. I think of two negative things of saying IESG. First that IESG may disappear and it would be unclear where this power goes. Secondly, that it may be interpreted that IESG has the right to say no over the community about updates.
Section 2.3:" Standards-track registrations may be updated if the relevant standards are updated as a consequence of that action. Non-standards-track entries may be updated by the listed responsible party."
There is an inconsistency here. Shouldn't this text refer to the listed "change controller"?
- Jari Arkko: Comment [2008-04-23]: A lot of draft-hansens, draft-klensins, draft-melnikovs, etc. Documents that are discussed on specific mailing lists around a topic. I counted over 60% individual submission rate over WG submission rate on the APPS area. Good documents. Necessary documents. Stuff that should be done. But are you sure you don't need more WGs? I do a lot of individual submissions too, but I also find that WG documents do get more review, more exposure from the IETF community, easier to delegate work to chairs, etc. Is there something that blocks us from having more WGs to look at these things, e.g., around e-mail? Are the updates too spread out to define a useful WG for them? Or does our process of starting up a WG have a too high bar?
Telechat:
- Chris: Jari's comment, history of pushback on generic WGs in Apps; current Apps ADs more willing; I push back on some Individual Submission
- Lisa: we discussed on apps list, people liked individual submissions
- Lisa: we would have more WGs if folks would write charters; we tried writing them ourselves, didn't work
- Chris: ietf-smtp list might be better review than a new WG
- Jari: could we just change its name
- Chris: I'm not concerned about review of this draft. I will continue pushing, maybe IMAP extensions WG
- Chris: re Cullen, read 4020, procedures effectively useless, rfc-ed note to delete 4020 ref, therefore no difference
- Cullen: removes ability to get early registration.
- Chris: this is not a stds-action, this is a spec-req
- Chris: Magnus re IESG-vs-IETF; no effective difference, don't want to push back in this case, IESG direction has been confusing in past
- Magnus: second one minor
- Cullen: cleared
- Chris: AD followup
- Sieve Email Filtering: Environment Extension (Proposed Standard)
draft-freed-sieve-environment-05.txt
Note: Alexey Melnikov is document shepherd
Token: Chris Newman
Discuss:
- Pasi Eronen: The document goes much beyond providing information about the Sieve interpreter environment; it also provides information about the SMTP (or similar) connection used for delivering a particular message. This is really a property associated with the message, not the interpreter.
Even if both of these features are provided in the same document, the abstract, introduction, and other places should more accurately describe the scope. Defining two separate test names would clarify the situation considerably; at the very least, Section 4.1 should be split to two subsections, one for each type of information.
- Magnus Westerlund: Comment [2008-04-24]: Section 6: Contact address: Sieve discussion list <ietf-mta-filters@imc.org>
Shouldn't this say: IETF, Sieve WG mailing list <ietf-mta-filters@imc.org>
To make it clear that it is an activity of the IETF? So that one knows where to go when this address doesn't work.
Telechat:
- Pasi: describes only one part
- Chris: common practice to use same syntax for different types of info; I thought it resolved; both are part of transport
- Pasi: document needs to make distinction between environments, even if syntax is the same
- Chris: I don't expect substantive change if I do push back (gently): is it worth the effort?
- Pasi: it is a goal to have things perform differently on different servers, not when from different senders; probably not worth fighting, but clarification, I'll send text
- Chris: AD followup
2.2.2 Returning Items
3 Document Actions
3.1 WG Submissions
3.1.1 New Items
- Policy-Enabled Path Computation Framework (Informational)
draft-ietf-pce-policy-enabled-path-comp-03.txt
Token: Ross Callon
Discuss:
- David Ward: It would be very helpful to put a listing of policy attributes that are under consideration in a section before the scenarios. The scenarios are very helpful as examples but, they are limited in their usefulness to understand what attributes and constraints are to be used to create policy. The doc is theoretical enough on the discussion of policy that it becomes unclear the actions that are to be taken.
There is also little discussion on the policy distribution mechanism when the PCC is separated from the PCE. It would seem an important part of the framework and some more text is required to understand what is necessary.
There are statements that COPS is not required but, it is referred to throughout the doc. If it is not required what is another technique that could be used, recommended or is going to be followed in the WG?
- Jari Arkko: Comment [2008-04-24]: I am concerned of a number of things with this document. The main issue is that it introduces a level of generality that I'm not sure is called for and brings along with significant complexity. Policy can be applied and fetched from either clients or servers. Policy can apply to actual PC decisions, but also to selection of PCEs. The components necessary to implement this architecture are going to be numerous. Does the industry really need all this, or was the inclusion of all of these options part of some compromise?
Also, I was earlier under the impression that COPS is dead, and as a result it might not be such a good idea to build on it. Maybe that is not the case?
Telechat:
- Ross: looks to be best handled offline with revised I-D; I'm not a COPS expert. We'll take it offline
- Jari: my concern: so much stuff, why do we need all this
- Ross: "policy" is often hand-waving; configuration knobs are desired by users; to me whole document not critical, but useful info
- Jari: policy must be at every box, centralized functions should be called on demand
- Dave: centralized policy calculations is a very hot topic; details really aren't known
- Ross: fundamental argument in the WG
- Dave: this one is not critical to anything they're actually building;
- Ross: this is discussing something possible in principle, we'd have to be very careful if STD, if Info crisper language needed; will be Revised I-D; will send email to authors, etc
3.1.2 Returning Items
3.2 Individual Submissions via AD
3.2.1 New Items
- Memorandum for multi-domain Public Key Infrastructure Interoperability (Informational)
draft-shimaoka-multidomain-pki-12.txt
Token: Russ Housley
Discuss:
- Jari Arkko: I found this document useful, and a surprisingly easy read. Like Chris I wonder how practical the more complicated architectures are. But that is not something we can ask to be fixed in the document. In any case, I wanted to correct a specific few issues:
Definition: A system of CAs that perform some set of certificate management, archive management, key management, and token management functions for a community of users in an application of asymmetric cryptography and share trust relationships, operate under the same Certificate Policy Document specifying a shared set of policy OID(s), and are either operated by a single organization or under the direction of a single organization.
What is the term that is being defined here? No term is listed above. The title of the section, PKI Architectures, also does not seem to be something that matches the above definition. Please clarify/reword.
PKI Domain: A set of two or more PKIs that have chosen to enter into trust relationships with each other through the use of cross-certificates. Each PKI that has entered into the PKI Domain is considered a member of that PKI Domain.
...
o Two or more PKI Domains may enter into a trust relationship with each other. In this case, they may combine into a single PKI Domain or retain the existing PKI Domains and define a new PKI Domain with the existing PKI Domains as members.
These two definitions seem contradictory. The first one says that a trust relationship between two PKIs implies a PKI Domain. The latter says that its something you can choose to have, but do not have to. I think the confusion comes from what Section 3 specifies about DPOIDs. Is a PKI domain definition dependent on (a) existence of a trust relationship and cross certs, or (b) common DPOIDs? Suggest either modifying the latter definition or taking the existence of a domain specific DPOID as a requirement in the first definition.
In order for a PKI to participate in one or more PKI Domains, that PKI must have the following:
o One or more Policy OID(s) defined in the Certificate Policy Document that are also asserted in all certificates issued by that PKI.
Given a statement from start of Section 3: "A domain Policy Object Identifier (OID) is a policy OID which is shared across a PKI Domain. Each CA in the PKI Domain must be operated under the domain policy OID.", I would have expected to see a requirement on DPOIDs, too.
Comment [2008-04-24]:
Prior to establishing the trust relationship, each PKI determines the level of trust of each external PKI by reviewing external PKI Certificate Policy Document(s) and any other PKI governance documentation through a process known as policy mapping.
This seems to forget the business and real-world aspects that appear to be in far greater role in determining whether to enter a relationship. Suggest edit: s/Prior to establishing the trust relationship/In addition to making a business decision to consider a trust relationship/
PKI Domain: A set of two or more PKIs that have chosen to enter into trust relationships with each other through the use of cross-certificates. Each PKI that has entered into the PKI Domain is considered a member of that PKI Domain.
NOTE: This definition specifies a PKI Domain recursively in terms of its constituent domains and associated trust relationships; this is different to the definition in RFC 4949 [RFC4949] that gives PKI Domain as synonym for CA domain and defines it in terms of a CA and its subject entities.
Personally, I find the terminology domain unfortunate in this context. A federation, group or some other term would perhaps be more appropriate.
I found it amusing that on Page 27 there is a small section that defines the used acronyms, such as "PKI". I'm almost certain that this acronym occurred earlier in the document :-) Perhaps this section should have been merged with the terms section in the beginning of the document.
I fear that no one will in practice be able to get what Section 3.2.3 says quite right. Managing these is going to be extremely difficult for everyone except perhaps a few of the most devoted organizations. Assuming there are domains and membership in multiple domains. Do implementations typically get policy mapping and name constraint correctly? I wonder...
- Chris Newman: Comment [2008-04-23]: The true security of these models depends heavily on the diligence of the humans applying policy and operations as well as the people writing the software. PKI software has a long history of introducing security bugs into deployed systems simply as a side effect of the complexity of standards such as ASN.1 and PKIX. I find myself skeptical that humans can actually implement and apply the policies necessary to make the more complex PKI structures reasonably secure in practice. While these concerns could be better captured in the security considerations and that would result in a minor improvement to the document, at the root this is not an actionable concern absent significant research into practices necessary to make security policy operations actually effective.
Editorial nits:
Section 2.2.1: 4949 [RFC4949]. The first definition (context for PKI) is specifically used to 'Trust Anchor CA' in this document.
I'm not sure what this means, perhaps you meant to say:
4949 [RFC4949]. The first definition (context for PKI) is referred to by the terminology 'Trust Anchor CA' in this document.
or
4949 [RFC4949]. This document uses the terminology 'Trust Anchor CA' for the first definition (context for PKI) of 'Root CA' in RFC 4949.
Section 2.3.2.3: appropriate certification path to a subscriber if they chooses an
s/chooses/choose/
Telechat:
- Russ: Jari; concern with PKI
- Jari: two inconsistent definitions, might form new PKI domain or not
- Russ: will be AD-followup
- Russ: -11 and -12 not the same
- EAP Tunneled TLS Authentication Protocol Version 0 (EAP-TTLSv0) (Informational)
draft-funk-eap-ttls-v0-04.txt
Note: Laksminath Dondeti is the Document Shepherd
Token: Jari Arkko
Discuss:
- Pasi Eronen: Section 9.2.1 or 14 needs to describe downgrade attacks against version negotiation (since the EAP-TTLS header is not integrity-protected).
Section 10 says "Specifically, the AVP Codes used in EAP-TTLS are semantically equivalent to those defined for Diameter, and, by extension, RADIUS. Also, the representation of the Data field of an AVP in EAP-TTLS is identical to that of Diameter."
This statement should be updated to reflect the last paragraph of Section 16. Something like this:
"Specifically, although EAP-TTLS uses the same AVP Codes and syntax as Diameter, the semantics may differ, and most Diameter AVPs do not have any well-defined semantics in EAP-TTLS. A separate "EAP-TTLS AVP Usage" registry lists the AVPs that can be used within EAP-TTLS and their semantics in this context (see Section 16 for details)."
The document also should explicitly say that an EAP-TTLS server MUST NOT copy AVPs from EAP-TTLS to RADIUS/Diameter messages unless the server understands that AVP, and its semantics within EAP-TTLS have been defined. (Copying unknown AVPs could lead to security problems.)
There seems to be two different ways to encode vendor-specific AVPs (such as MS-CHAP-Response): setting the V bit and placing Vendor-ID in the AVP header, or clearing the V bit and using AVP code 26. Although Section 10.3 seems to say something about this, it falls short of actually saying which format(s) MUST be used or supported when e.g. implementing MS-CHAP/MS-CHAPv2 in Sections 11.2.3/11.2.4. (What do existing implementations do?)
The document should say something about EAP-Message attributes and fragmentation. Diameter doesn't use >253 byte EAP-Message attributes; it has a separate EAP-Payload AVP. Does EAP-TTLS inherit the 253-byte restriction from EAP-Message RADIUS attribute? Is the recipient required to support reassembly? Or is the EAP-TTLS server required to do fragmentation/reassembly if passing this to RADIUS backend? (What do existing implementations do?)
Section 11.2.1 needs some additional text, since EAP (as defined in RFC 3748) cannot be initiated by the client sending an EAP Response. You could specify e.g. that an EAP Identity Request (with identifier 0 and empty contents) is sent, but it's "compressed" to zero bytes on the wire, but the client behaves as if it had received this packet.
Section 11.3 probably needs some more details, since RFC 3748 does not describe how a sequence of EAP methods would work (and explicitly forbids such sequences outside tunnels). For example, will there be several EAP Identity exchanges? Are you required to run a method to a well-defined point (where normal EAP would allow you to return EAP Failure and/or EAP Success), or can you abandon a method in a middle of an exchange?
- Chris Newman: I believe this proposal would be significantly improved by adding support for channel bindings (RFC 5056), and that doing so would not require a great deal of effort. Basically, this would define the rules for extracting channel binding information from EAP-TTLS so that an EAP mechanism with channel bindings could then use that information.
- Tim Polk: The client initiated EAP authentication described in 11.2.1 would seem to break the EAP state machine. At a minimum, the document needs to describe how an eap-ttls implementation affects the state machine and (hopefully) why this is safe in the given context/environment.
- Russ Housley: Comment [2008-04-24]: Section 9.2 indicates that AVPs may be sent in the clear in the initial Start packet from the server. Possible uses are indicated in the text. However, it is unclear which AVPs are allowed to appear here.
Joel Halpern suggested in his Gen-ART review an additional sentence at the end of the first paragraph of section 11.3: "Multiple authentication is only supported by this protocol in conjunction with EAP."
Telechat:
- Jari: must address Pasi, need new draft
- Jari: Tim's issue, can be made to work; could pretend you received identity request; new text in tracker
- Chris: health-warning is sufficient for me
- Tim: I read the new text, it's fine with me
- PKCS #8: Private-Key Information Syntax Standard Version 1.2 (Informational)
draft-kaliski-pkcs8-00.txt
Token: Russ Housley
Discuss:
- Pasi Eronen: This is a "discuss" discuss; I expect to clear or change to normal discuss after the telechat.
If this was a normal IETF document, I'd have a list of things that need to be fixed, mostly of semi-editorial nature. For example,
- split references to normative and informative
- say something about file formats (how you store PKCS#8 objects in a file in interoperable way)
- explain better how attributes are supposed to be used
- give some more concrete recommendations about encryption (to achieve interoperability)
- say something about I18N when the encryption key is a character string typed in by the user
- explain relationship to other standards or de-facto conventions for storing private keys
However, since this document attempts to be a word-by-word republication of an existing document, and the intent of transferring change control is to update the document relatively soon in IETF, perhaps these changes could be done in that update.
Should there be e.g. in IESG note saying that the document is known to be lacking in some areas, and an update is expected to improve it?
Telechat:
- Russ: Pasi, given what we're trying to do is transition change-control into IETF
- Pasi: happy with IESG note
- Russ: concerned with tone; need to be backwards-compatible; brought into IETF; what do you want in IESG note
- Pasi: boilerplate, status of this
- Chris: abstract plus boilerplate is fine
- Jari: two aspects, will be need for further work
- Russ: history PKCS7 brought in as info; three features added; same path here?
- Russ: thank RSA for contribution, future standards work based on this is expected (one case is version number is needed); I'll draft language during break
- Cindy: approved, pending language from Russ
1246 EDT break
1252 EDT back
Cindy: Russ text in jabber
3.2.2 Returning Items
3.3 Individual Submissions via RFC Editor
3.3.1 New Items
3.3.2 Returning Items
4 Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
4.1.2 Proposed for Approval
- NETCONF Data Modeling Language (netmod)
Token: Dan
Telechat:
Cindy: do we postpone
[postponed to end of meeting, hoping Ron will become available; see "Agenda Item Continued" below]
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
4.2.2 Proposed for Approval
5. IAB News We can use
6. Management Issues
- Can milnet-parameters be made historic? [IANA #164095] (MichelleCotton)
Telechat:
- Michelle: process
- Russ: old registrations still publicly available
- Michelle: yes, send note to IANA, question of historic
- Russ: Bob Braden asks we document reclassification in an RFC; retreat topic
- Michelle: do we need any time of LastCall
- Russ: Let's just do it
- Michelle: we're finding more dinosaur registries
- IESG Note for RFC 5000 (Russ Housley)
Telechat:
- Russ: mgmt item RFC 5000, making previous STD 1 historic, fine with them
- Sandy: drafted text to go into RFC 5000
- Russ: any objections to putting this in IESG note
Agenda Item Added:
- Magnus: linking discuss to issues; Henrik started writing something to link Issue-tracker
- Chris: Issues going back to author could use better tracking; now need to research several
- Russ: should talk about tool enhancement some other time, issues of getting out of sync
- Jari: more complicated than you thint
- Pasi: worry that people take a bookkeeping tool (discuss) more seriously than they deserve; may need better explanation before making it more public
- Russ: I'll add Tools to the retreat agenda
7. Working Group News
- Lisa: at retreat, adding Boston thing, may arrive late
- Russ: when IAB retreat is over I'll post a draft IESG retreat agenda
- Pasi: proposed IPsec extensions WG; drafting work items
- Russ: some posters wanted limits
- Pasi: no new items without rechartering
- Russ: IPR documents expect on agenda 2 weeks
- Cullen: ongoing discussion of P2Pi
- Mark: TICTOC interim
Agenda Item Continued:
- Cindy: back to NETCONF
- Russ: huge amount of discussion; all process discussion
- Cullen: who is the "we" of consensus?
- Russ: design team recommended a charter, lastcalled on IETF list
- Chris: I commented, but was in rough
- Russ: we're trying to determine consensus on the path recommended by design team
- Russ: any objections to chartering
- Chris: we will need to document YANG language the usual way
- Russ: approved pending naming of chairs
1323 EDT Adjourned