Internet Standards

home *** CD-ROM | disk | FTP | other *** search

/ Internet Standards / CD1.mdf / MISC / MERIT / 1992 / 92_035.TXT < prev next >

Wrap

Text File | 1992-01-23 | 35.8 KB | 1,298 lines

X3S3.3/92-035 To: X3S3.3 Membership January 8, 1992 Subject: NLSP and TLSP initial ballot comments Enclosed with this message are the initial ballot comments for NLSP and TLSP. Part of these comments came from the adhoc meeting that we had in Orlando and the rest are from NIST. I have not included either the comments from Tassos or NATO as there has been no decision from X3S3.3. I had asked that the membership read these comments and hopefully come to closure. To help in coming to closure, I have invited an individual from NSA to the Tucson meeting. He will explain the rational for the NATO comments. I hope that X3S3.3 accepts the NATO comments as I believe that the modularity that we desire in the security protocols (Separation of the Security Association Establishment Protocol from the secure communication protocol) is the aim of their comments. I will find out from both the UK and Canada their position on the NATO comments. As stated in the last email, I hope that the majority of work on the ballot comments can be done before the Tucson meeting. If you have misplaced the NATO comments that were sent in the prior message please ask and I'll resend the comments via email. Thanks Dale NETWORK COMMENTS Initial comments on ISO CD 11577 (Network Layer Security Protocol) Item Number: 0 Type of Comment: General Location: Various Rationale: The protocol as written has the secure communication functionality merged with the security association, encipherment/decipherment functionality, and padding functionality. Rather then treat this as one protocol it should be viewed as a protocol with many parts or functions. This is more a descriptive technique but is necessary for progression. Proposal: Take the following examples of how this security independence can be added to this document. Item Number: 1 Type of Comment: Editorial Location: Beginning of document Rationale: For clarity need a table of content that is more detailed and corresponds to the page number. Proposal: Add the full Table of Content functionality. Item Number: 2 Type of Comment: Editorial Location: Page 1-2 Rationale: The reference should be to both seven and eight. It would also help if the reference was to a specific sub section(s) of either seven or eight. Proposal: Add the appropriate subsection(s) for both seven and eight. Item Number: 3 Type of Comment: Editorial Location: 0 First paragraph last sentence. Rationale: For clarity reasons the word protection should be replaced by the word security. Proposal: Replace the word "protection" with the word "security" . Item Number: 4 Type of Comment: Editorial Location: 0 Second paragraph first sentence. Rationale: It is hard to understand what is meant by assurance levels from low to high. Proposal: Last part of this sentence should read "... of assurance/security levels." Item Number: 5 Type of Comment: Question Location: 0 Second paragraph second bullet item Rationale: We found this phrase difficult to comprehend. Proposal: Add text to clarify the meaning of the second bullet item. Item Number: 6 Type of Comment: Editorial Location: 2 Rationale: ISO 9979 referred to in section 6.2 j) not included in references. Proposal: Add document reference. Item Number: 7 Type of Comment: Editorial Location: 5.1 third paragraph Rationale: This paragraph talks about high security and optimized performance - two terms which are not actually defined. The point of this paragraph is that the no header option can be used which may not give the full degree of security that is available in the full header option but the user gains in that performance is not overburdened (this is referring to those networks that use X.25. The only the security service required is confidentiality and no integrity). It seems that we should spell out exactly what is being offered. Proposal: Delete this paragraph and give a brief description of the no header and header option of the connection oriented security protocol. Item Number: 8 Type of Comment: Minor Technical Location: 5.1 Item 1 and 2 and paragraph 5 Rationale: Items 1 and 2 state that at the upper boundary a secure connection or connectionless network service is provided. Paragraph five states that the protocol provides the same mode of service at the upper and lower boundaries. Seems like the two items are incorporated into the fifth paragraph and therefore not needed. Proposal: Remove items one and two in first paragraph and change word "is" to "it's" Item Number: 9 Type of Comment: Minor Technical Location: 5.1 second paragraph Rationale: The term NLSP address is not defined. It seems like the term NSAP address is what is needed here and in other places in the document. Proposal: Change NLSP address to NSAP address where appropriate. Item Number: 10 Type of Comment: Editorial Location: 5.1 sixth paragraph second sentence Rationale: Word "may" seems inappropriate for this sentence. Proposal: Change word "may" to "should" in this sentence. Item Number: 11 Type of Comment: Technical and question Location: 5.1 last paragraph Rationale: The term "target protection QoS" needs to be defined. We also offer in our comments on the Lower Layer Guidelines a brief description of QoS. The NLSP may point to this document for further clarification on QoS. Proposal: Add appropriate text after the QoS issue is resolved for all lower layer security standards. Item Number: 12 Type of Comment: Editorial Location: 5.2 first and second paragraph Rationale: This paragraphs have been rewritten and combined for better clarity. Proposal: Replace this paragraph with this sentence. NLSP provides the security services identified in ISO 7498-2 that can be used in conjunction with the OSI NL services as defined in ISO 8348 and ISO 8348/AD1. NLSP also supports optional primitives parameters (as defined in DIS 10028) which are applicable when NLSP-CO is operating in an Intermediate System Item Number: 13 Type of Comment: Minor Technical Location: 5.2 Items 1-5 under NLSP-CL and NLSP-CO Rationale: The specific security service is listed with what appears to be the mechanism for obtaining this service. The standard would be clearer if this was stated explicitly. Proposal: Example : 1: Data Origin Authentication - this standard supports this security service. The mechanism used for this service is ICVs in conjunction with key management. Also under traffic flow confidentiality address hiding should state that it is the source and destination address of the end system that are hidden. Item Number: 14 Type of Comment: Editorial Location: 5.3 First Paragraph Rationale: The term black network is used with no explanation of what is a black network. The term red network is also implied in this document. Within the US there could be some racial connotation associated with these two terms. Proposal: Either eliminate these terms altogether and replace with secure and non secure network communication or in the definitions section define both red and black networks according to the definitions used in the security community and then state that in this document we will use the terms "secure and no secure network communication". Item Number: 15 Type of Comment: Question/Technical Location: 5.3 two bullet items under paragraph 3. Rationale: Is it necessary to use NILS or is this just a modelling concept in the first bullet item. In the second item what is meant by the term notional interface and is NILS also required. NILS may be useful in modeling the interface but is it always necessary? Proposal: Define when NILS is applicable in the modelling of this interface and what is meant by the term notional interface. Item Number: 16 Type of Comment: Editorial and Minor Technical Location: 5.4 second paragraph Rationale: The term should be Security Association Establishment Protocol not SA-Establishment PDU. NLSP needs to determine if an association has been established that can be used. If there is not one available then NLSP must either recognize the out-of-band establishment of an association or to establish an in-band one. Proposal: Change SA-Establishment PDU to Security Association Establishment Protocol. Add concept that NLSP will determine if an association needs to be established or if an existing one can be used. Item Number: 17 Type of Comment: Editorial Location: 5.4 last paragraph Rationale: The references need to be corrected and the word common should be added to the second sentence. Proposal: Add word "common" between "The" and SA-Attributes. Change 6.3 to 6.2 and 8.3 not 8.2. Item Number: 18 Type of Comment: Minor Technical Location: 5.5, second paragraph Rationale: The last phrase of the paragraph "using the integrity key attribute of the SA" is not defined. It is not clear why this phrase is required as the prior wording conveys what is to be done. Proposal: Define the term in the attribute section and add the reason why it needs to be referenced or eliminate the phrase. Item Number: 19 Type of Comment: Editorial Location: 5.5 third and fourth paragraph Rationale: For clarity the third paragraph should be rewritten. Proposal: Replace the second sentence with the following: The length of the padding field is computed using the requirements of traffic padding, Integrity mechanism (ICV), and Confidentiality mechanism (Encipherment). See 9.3 for placement. Fourth paragraph replace "for" with "indicated". Item Number: 20 Type of Comment: Editorial Location: 5.6 first paragraph, second sentence Rationale: Clarity Proposal: After word "This" add "Secure Data Transfer PDU" Item Number: 21 Type of Comment: Editorial Location: 5.6, second paragraph Rationale: Clarity Proposal: Replace "deciphers and ... " with "executes the appropriate security mechanisms on the Secure Data Transfer PDU and extracts the NLSP-CL Userdata". Item Number: 22 Type of Comment: Editorial Location: 5.7.3, first paragraph Rationale: Clarity, the extra words are not necessary. Proposal: Remove the two words "just using" Item Number: 23 Type of Comment: Minor Technical Location: 5.7.3, second paragraph Rationale: The no header option can be selected if only confidentiality service is required. Proposal: Reword to show that it is not the ICV function but that only confidentiality can be requested with the no header option. Item Number: 24 Type of Comment: Question/Minor Technical Location: 5.7.4 second paragraph Rationale: Since the no header option allows for the confidentiality service only(this does not increase the size of the user data field) it is not apparent why this information may be segmented? Proposal: Either remove the last part of the second sentence starting with the word "or any..." or give an explanation as to why this is required. Item Number: 25 Type of Comment: Major Technical Location: 6.2 - Common Security Association Attributes Rationale: Many assorted attributes can be attributed to a security association. For example, one could include attributes to maintain the counts (and counter thresholds used to emit notifications) of the various security errors that can occur. This of course quickly becomes an exercise in defining elements of managed information for OSI Systems Management, rather than identifying those attributes that are needed by NLSP. To avoid this exercise, it is proposed that in the NLSP standard, only those attributes that are actually conveyed during security association establishment be attributed to the security association. Application of this criteria would eliminate spurious information and therefore improve the clarity of the standard the standard. Proposal: a) III) Delete SAID_Len since it is attributed to be part of an ASSR, whose contents are not explicitly defined in this document. d) Delete Adr_Served since it is clearly management information and contrary to its definition, appears not to be included in section 9 for exchange during SA establishment. e) Delete ASSR_ID since it is part of an ASSR, whose contents are not explicitly defined in this document, and contrary to its definition, appears not to be included in section 9 for exchange during SA establishment. Note too that implication that all security rules are registered and have object identifiers assigned to them, is not valid. Item Number: 26 Type of Comment: Major Technical Location: 6.2 a) Rationale: The SAID_Len attribute is use to unnecessarily restrict the size of the SAID of both parties to be the same. There is no need to restrict the length of one parties SAID to that of the other. However, a maximum length is reasonable and should be defined in section 9.2. Proposal: Make My_SAID and Your_SAID to be an integer of range 0 to (127 ** maximum_length) - 1. Delete SAID_Len. Item Number: 27 Type of Comment: Minor Technical Location: 6.2 b) - Direction Flag Setting Rationale: The description given is only applicable when NLSP is used to establish the SA. If, for example, the SA is manually pre- established the definition no longer applies. Proposal: Change the description to: "This attribute indicates how the initiator to responder flag should be set to detect reflected PDUs." Item Number: 28 Type of Comment: Minor Technical Location: 6.2 l) Padding Mechanism Attributes Rationale: In 6.2 i) the ICV_Length is already defined and should be equivalent to ICV_blk. Similarly, Enc_Blk is more acceptable as an attribute of k), an encipherment mechanism attribute. Proposal: Delete ICV_blk from this subsection. Also move Enc_Blk from here to subsection k), as an encipherment mechanism attribute. Item Number: 29 Type of Comment: Editorial Location: 6.4 - In-Band Method Rationale: The term "SCI exchange PDUs" is inexact and may be confusing to the reader. SCI is defined earlier in the document in terms of PCI which in turn is used in the definition of PDU (in ISO 7498). Proposal: Change all referenced from "SCI exchange PDUs" to "SA establishment PDUs. For example, the second paragraph in this section would become: A security association establishment protocol is carried out by exchange of SA establishment PDUs. Item Number: 30 Type of Comment: Major Technical Location: 6.4, last paragraph, second sentence Rationale: The sentence "It is strongly recommended that an asymmetric algorithm be used." seems to not belong in a standard. An SC6 goal in the development of lower layer security standards has to decouple the different algorithms from the communication protocol. It seems that this sentence adds nothing to the standard itself, but would imply that symmetric algorithm are not as good for this functionality. Proposal: Remove the second sentence. ANSI X9.17 could be used as an example of a symmetric algorithm. The US is not able to supply text at this time but will before the next SC6 meeting in July of 1992. Item Number: 31 Type of Comment: Minor Technical Location: 7.1, first paragraph and 8.1 Rationale: The parameters all start out with NLSP. This seems redundant as NLSP is part of the Primitives. Proposal: Remove NLSP from the Parameters. Instead of NLSP Called Address the new parameter would be Called Address. The sentence "The following parameters..." should be replaced with "The above parameters (excluding QoS) are equivalent to the following parameters as defined in ISO 8348/Add1. Destination Address Source Address Userdata Make similar changes to 8.1. Item Number: 32 Type of Comment: Question/Technical Location: 7.1 Table a Rationale: There is no confirm or response primitive used in the NLSP Connectionless situation. It is not clear why only the security label parameter remains the same for both the request and indication. If this is the only one that can not change then a statement to that effect plus the reason would be appropriate. Proposal: Eliminate words confirm and response in the Note. Either state the rationalization why only the security label cannot be changed from the request to the indication or allow the other parameters be the same. This seems to be related to the QoS issue as to what security parameters can change and which can go to a lower or higher priority. Item Number: 33 Type of Comment: Minor Technical Location: 7.2 Rationale: The "BN" which is part of each parameter is not needed as it is already part of the primitive. Proposal: Remove the "BN" part of each parameter. Item Number: 34 Type of Comment: Major Technical Location: 7.3 and 8.3 Rationale: The text on keys under category (a) appears to be in error. The text about encryption/decryption keys in categories (c) and (d) is overly restrictive. While two active decryption keys is the most logical choice (previous/current) it does not follow that there should be two encryption keys as well. One would suffice. Overall, there is no reason why one should become fixated with the number of keys (two or more). Finally, it is the crypto machines that need access to the keys, not the NLSP protocol. Proposal: Remove restrictions Item Number: 35 Type of Comment: Major Technical Location 7.5 - In-Band SA Establishment Rationale: The description of the in-band SA establishment implies that a connection oriented protocol is required. Memory of past PDUs sent and received, their sequence and elapsed time as indicated in the second paragraph of this section constitute a connection oriented protocol. This implication should be made explicit. Proposal: Add to the beginning of the second paragraph: "The SA establishment protocol is a connection oriented management protocol. The protocol entity maintains a memory of PDUs exchanged, their order of occurrence, and elapsed time from transmission." (The description and protocol exchange that is used in IDRP may be appropriate for this functionality). Item Number: 36 Type of Comment: Major Technical Location: 7.5, 9.1, and elsewhere Rationale: The diagram below illustrates a requirement for a new NLSP PDU type, for use by a connectionless security protocol entity to discover the peer with whom to form a security association. In this example, two trusted networks are protected from an untrusted or "black" network through several network level gateways, X,Y and Z, containing NLSP. If party A attempts to communicate with party B, the NLSP entity in gateway X would need to form a security association with a peer NLSP entity in either gateway Y or Z. Currently, there is no means to discover which gateway has or is capable of accepting this responsibility. Proposal: Add a new NLSP PDU type, the Probe PDU, to the list of types in section 9.1. The Probe PDU would be used by a NLSP entity to discover the address of a peer in situations such as that described above. Discovery is achieved by addressing the Probe to the destination entity, in the example given party B. A peer NSLP entity at the gateway, in the example either Y or Z, having responsibility to protect party B is expected to intercept the Probe and respond with its own Probe (reply) conveying the previous probe information along with its own network address. If such an exchange is successful, a security association may be formed by the pair of NLSP entities, perhaps through use of source routing capabilities of the untrusted or "black" network. Item Number: 37 Type of Comment: Major Technical Location: 7.6.1 Rationale: It is not the NLSP-address but the NSAP address that is checked in reference to the security label. Proposal: Replace the first sentence with the following. The NLSP- CL checks that the NLSP-Cl_Source_Address is an NSAP address served by this NLSP-CL entity. Item Number: 38 Type of Comment: Minor technical Location: 7.5, second paragraph Rationale: It is not clear what is a specified timeout when dealing with a connectionless security protocol. This concept needs to be thoroughly documented as it may have an adverse affect on the performance of this protocol. Proposal: Define the term "specified timeout" and how it is used in this protocol. Item Number: 39 Type of Comment: Major Technical Location: 7.6.4 Rationale: When both Integrity and Confidentiality are selected the Integrity function is performed before the encipherment function. Proposal: Move the first sentence to the end of the paragraph. Change the title to " Calculation of ICV and Encipherment". Item Number: 40 Type of Comment: Major Technical Location: 7.7.9.1, second paragraph Rationale: The term "address of the NLSP SAP" is not defined. Proposal: Replace this with the following term "end system NSAP address". Item Number: 41 Type of Comment: Question/Technical Location: 7.7.9.2 - 7.7.9.2.3 Rationale: The text indicates that the security label value, confidentiality indicated value, and/or integrity indicated value are passed to the NLSP user as part of the indication parameter. It is not clear how this is done. Proposal: Supply appropriate text on how this is conveyed to the NLSP user. Item Number: 42 Type of Comment: Major Technical Location New 7.7.9.3 Rationale: Details that refer to the protocol itself are missing (e.g.,when an NLSP PDU is received, one must not simple decrypt and check the ICV, one must eventually recreate the original PDU by removing the extraneous fields and hand over this PDU to the next higher protocol. Proposal. Have a paragraph which states what is done to the secure PDU and what is forwarded to the next protocol. Item Number: 43 Type of Comment: Minor Technical Location: 8.5.1.2 Rationale: It seems that the main point of this paragraph is that NLSP can be deployed in any network but used only when that network connection needs security. The US had a hard time determining if this was the intention of this paragraph. Proposal: Rewrite this paragraph to convey this idea. Item Number: 44 Type of Comment: Major Technical Location: 9.3, 9.4, 9.5 Rationale: There are three different pdus referenced but it is not clear how they are differentiated. The second two use a control octet to indicate the type of pdu whereas the first pdu the second octet is a length field. Proposal: Add a control octet to the first pdu or have a different Protocol ID for the two pdus associated with the security association establishment protocol. Technical content field can be zero if no header option is used? Item Number: 45 Type of Comment: Technical Location: 9.3 Rationale: The note indicates that there is no padding field when the no-header option is selected. Are there other fields also not used when the no-header option is selected i. e,. ICV, Clear Header, and any content fields? Proposal: Explain what the no-header option is and what is not carried with it. Rather than a note this should be a main paragraph. Item Number: 46 Type of Comment: Major Technical Location: 10 Rationale: Either a PICS is needed for this standard or the clauses need to be referenced when indicating what are the conformance requirements. Proposal: Add the appropriate clause number when a requirement is identified or add a PICS. Item Number: 47 Type of Comment: Major Technical Location: Appendix C Rationale: In the prior version of this document there was a figure which showed the exchanges required to perform the Diffie-Helman algorithm. This picture was a help in understanding the protocol. There is also a very good writeup in the National Computer Security Conference Number 13 which could be used or referenced as a more detailed explanation of this algorithm. It is also not clear how this algorithm is to be differentiated from any other algorithm. It seems that the first exchange must be to just agree on what algorithm should be used to establish the Security Association. Proposal: Add the picture and either reference the NCSC or add appropriate text to clarify the exchange. Add text to indicate that an exchange is needed to just agree on the type of algorithm to be used. Item Number: 48 Type of Comment: Major Technical Location: C.2 Rationale: Section C.2 has a misleading title. The exponential key exchange does not provide for NLSP Authentication (which is done with public/private keys and certificates). The problem is that exponential key exchange without authentication allows an in-between entity C to masquerade as A to B and as B to A and in the process eavesdrop on the whole conversation. Therefore, the exponential key exchange requires authentication via another set of keys. Beyond that, a better explanation is needed as to why authentication must follow key exchange rather than be carried concurrently. A possible explanation is not a straightforward replay attack as the text seems to imply but, rather, a replay attack by an entity that observed a past exchange, eventually computed x form a**x, and tries to pass itself as A. It should be noted that if this is likely, then the confidentiality of any dialogue is suspect (once I know x and a**y I can deduce the session key used). Finally, even if the above scenario is why the authentication follows the exchange, it is not obvious why four exchanges, exactly as described in C are needed. In conclusion: This is useful text that is insufficiently fleshed out and which belongs elsewhere (key management techniques). Proposal: Add appropriate text. Part of the above text could be used. Item Number: 49 Type of Comment: Location: Appendix E Rationale: The existing text appears to be Ok but insufficiently fleshed out. For instance, if CLNP is above NLSP, and if NLSP substitutes new addresses in the header, it appears that inconsistent routing may result (at least temporarily). Similarly, it is not obvious how NLSP will handle segmentation when encryption occurs after segmentation (in an IS) while decryption takes place in an IS that is co-located with the target ES. In short, we applaud the idea of including a tutorial and deplore the fact that the tutorial does not answer as many questions as it raises. Proposal: Time did not permit additional tutorial text. The US in a separate contribution will submit further tutorial text. CHARLIE 1. Proposed new text for "SCOPE" clause: This international standard specifies a protocol to be used by End systems and Intermediate systems in order to provide security services in the Network layer. This protocol resides in the Network layer, which is defined in ISO 8348 and ISO 8348/Add.2. The protocol described in this standard is called the Network Layer Security Protocol (NLSP). This international standard specifies: - methods for providing the following security services, which are defined in ISO 7498-2: * peer entity authentication * data origin authentication * access control * connection confidentiality * connectionless confidentiality * connection-mode integrity without recovery * connectionless integrity - the functional requirements for implementations that claim conformance to this international standard. The procedures of this protocol are defined in terms of: - service interfaces at both its upper and its lower protocol boundaries - requirements on the cryptographic techniques that can be used in an instance of this protocol - requirements on the information carried in the security association used in an instance of communications. Although the degree of protection afforded by some security mechanisms depends on the use of specific cryptographic techniques, correct operation of the security services provided by this protocol is not dependent on the use any specific cryptographic technique or any particular encipherment/decipherment algorithm: that is, the choice of a particular cryptographic technique is left as a local matter for the communicating systems. Furthermore, neither the choice nor the implementation of a specific security policy are within the scope of this international standard. The choice of a specific security policy, and hence the degree of protection that will be achieved, is left as a local matter among the systems that are using a single instance of secure communications. This international standard does not require that multiple instances of secure communications involving a single open system must use the same security protocol. secure communications within a single open system instances. 2. New Proposed Text for "INTRODUCTION": This international protocol is used to provide security services in support of an instance of communication between Network layer entities. This protocol is positioned with respect to other related standards by the layered structure defined in ISO 7498 and by the Network layer organization defined in ISO 8648. It provides security services in support of both the connection-oriented and the connectionless Network services. In particular, this protocol in located within the Network layer, and it has clearly defined service interfaces at both its upper and its lower protocol boundaries. 3. Although the abbreviation SNISP (Subnetwork Independent Security Protocol) is given in 4.4, this term is not defined within this standard nor is it referenced in clause 3. A definition of this term (or a reference to a suitable definition in another international standard) needs to be included in clause 3. 4. CD 11577 does not include a PICS. Hence, there is no way for a reviewer to discern which of its sections are normative and which are informative. The lack of an explicit PICS is further aggravated by the absence of normative language (e.g., use of the word "shall") anywhere in the bulk of the text except. for the conformance clause. Finally, the conformance clause (10 ff) is lacks cross references to the clauses that should (but in fact do not) contain normative descriptions for these functions. In summary, CD 11577 appears to have made no effort to allow a reviewer to identify and evaluate the normative aspects of this protocol. Until such material is provided, meaningful evaluation of CD 11577 can not be made. 5. The majority of the variables, constants, or parameters described in CD 11577 need to be described using ASN.1 notation. As an example instance, see clause 6.2. 6. CD 11577 has completely ignored management: that is, it is devoid of any Managed Objects. Is this an oversight, or is it deliberate? If it is an "unmanageable protocol", its usefulness will be severely limited. 7. There appear to be no clauses that deal with protocol-specific errors and that actions that need to be taken in response to them. As a byproduct, there is also no descriptions for the "notifications" that would need to be generated. 8. No finite state machine for the protocol is defined anywhere in 105836. TRANSPORT SECURITY COMMENTS DRAFT US COMMENTS ON THE TRANSPORT LAYER SECURITY PROTOCOL Item Number: Type of Comment: Editorial Location: 5.2 a) Rationale: The terms My_SAID and Your_SAID were introduced without regard to consistency to the existing text. In section 5.2 c), Peer_address, not Your_address is used to name the attribute containing the address of a peer entity. In section 6.4, peer address checking is applied to the address of the peer transport entity. Proposal: Replace these terms with the original: Local_SAID and Peer_SAID. Item Number: Type of Comment: Minor Technical Location: 5.2 b) Rationale: TLSP may not have established the SA as implied in this attribute definition. For example, it may have been manually established in the past. The actual use of the attribute is also not explained. Proposal: This attribute definition should be broadened to reflect its actual purpose: "This attribute indicates how the direction indicator should be set to detect reflected TPDUs." Item Number Type of Comment: Major Technical Location: 5.2 f) Rationale: Only optional mechanisms (i.e., labeling, confidentiality, and integrity) should be retained as attributes. SN, Padd, and PE-Authentication are mandatory mechanisms, much like reflection detection or address checking, which were correctly omitted. Proposal: Delete SN, Padd, and PE-Authentication from this section, since they are mandatory mechanisms that must always be available. Item Number Type of Comment: Major Technical Location: 5.2 g) Rationale: Since a security association can apply to more than one 8073 transport connection, the Conn_Label has no meaning as defined. Alternatively, one could expect that for per connection key granularity, either the negotiated label set would comprise a single element or the security rules would dictate the particular label within the set to use. Proposal: Delete the Conn_Label attribute from this section. Item Number Type of Comment: Major Technical Location: 5.2 g) Rationale: The label definition that appeared in earlier drafts of this standard was much better than the current one. Proposal: Amend the current label set definition with the previous label definition. Item Number: Type of Comment: Major Technical Location: 5.2 h) & j) Rationale: Although the current break out of key granularity into separate key granularities for integrity and confidentiality allows flexibility, it also complicates management if this flexibility is used. Proposal: Key granularity should be made a single attribute as it was specified in the previous version of this document. Item Number: Type of Comment: Major Technical Location: 5.2 h) & j) Rationale: The implication that the integrity mechanism may be based on a cryptographic algorithm is misleading and should be generalized to include non-cryptographically based algorithms. A similar generalization should include the possibility that more than one key is needed for an encipherment algorithm. Proposal: One solution is to define a new attribute combining all aspects of algorithmically based mechanisms, the algorithm mechanism attribute. Algorithm_Set: Set of { algorithm_identifier AlgorithmIdentifier, algorithm_type Enumerated{ crypto(0), non-crypto(1) } algorithm_size Integer, algorithm_mode Enumerated{ verification(0), generation(1) } } Item Number: Type of Comment: Major Technical Location: 5.2 h) & j) Rationale: The statement that the initial value of a key reference may change during the lifetime of an association is inconsistent with the protocol and would disable the capability to perform key replacement and signal this fact to a peer through the SAID (formerly key-id). Modification: Remove this statement from each section. Item Number: Type of Comment: Minor Technical Location: 5.2 i) Rationale: The SN mechanism attributes are artificial and have no direct bearing on the security association. One could suggest a large number of other such extraneous attributes dealing with security error counters and thresholds, access control issues, et cetera. However, it is preferable to leave these issues to a separate network management task. Proposal: Delete section 5.2 i) in its entirety. Item Number: Type of Comment: Minor Technical Location: 5.2 k) Rationale: In section 5.2 h) the ICV_Length is already defined and should be equivalent to ICV_blk. Therefore, the latter can be deleted. Similarly, Enc_Blk could be made an attribute of j), encipherment mechanism attributes and item k) deleted. Proposal: Move the Enc_Blk attribute to section 5.2 j) and delete section 5.2 k) in its entirety. need pics redone(postpone until we receive comments)