Regards~~~ -Sujing Zhou
Sam Hartman <[email protected]> 写于 2011-12-17 02:38:33: > >>>>> "zhou" == zhou sujing <[email protected]> writes: > > zhou> Hi,all, the following are questions occured to me when reading > zhou> draft-ietf-abfab-gss-eap-04: > > > zhou> 1. Section 1 "The Extensible Authentication Protocol (EAP) > zhou> [RFC3748] defines a framework for authenticating a network > zhou> access client and server in order to gain access to a > zhou> network." > > zhou> since applicability of EAP is under updating beyond network > zhou> access, I think the information of Section 7 might as well be > zhou> indicated here. > > I've opened issue #30 to track this. > > > zhou> 2. section 5.4.2 and section 5.7 Why would acceptor name > zhou> appear in a acceptor name request? > > The acceptor name request asks for a particular acceptor if the > acceptor is capable of acting as multiple entites/virtual hosts. > It's just like the Host header in HTTP or the server-name-indication in > TLS. > I'd be interested in any clarifications you can suggest so others don't > have the same confusion. While, I think 1. it better have a reference (I guess it is RFC6066) after " This is similar to TLS Server Name Indication", and have a brief explaintation about the use of Server name indication there, since it is not inlcuded in TLS but an extension, and may be not known by most people (like me :) ). 2. and better change the "Acceptor Name Request" to "Acceptor Name Indication" since it is REALLY easy to take "Acceptor Name Request" and "Acceptor Name Response" as a pair of requesting and answering the name of acceptor. 3. put some more explaining words in the beginning of Section 5.4.2 > > zhou> 3. section 5.4.3 "Typically this token would only be send if > zhou> the acceptor name request is absent." Acceptor name response > zhou> is sent only when no acceptor name request has been received? > > Jim proposed changing this at IETF 82 and I have seen no objections to > that change. > > zhou> 4. section 5.6 "After EAP success, the initiator sends a token > zhou> to the acceptor including additional subtokens that negotiate > zhou> optional features or provide GSS-API channel binding (see > zhou> Section 6.1)." > > zhou> According to RFC2743, GSS-API channel binding information > zhou> is provided as an input to GSS_Init_sec_context(), i.e., > zhou> before EAP sucess, so how and why send GSS-API channel binding > zhou> here? > > > It's not really true that gss_init_sec_context is before eap success. > You call it multiple times. > ONe of those times you need to send GSS channel binding data; the > section you quote describes how. > > > > zhou> 5. "The PROT_READY service is never available with this > zhou> mechanism." what is PROT_READY service? I cann't find any > zhou> reference to it. > Section 1.2.7 of RFC 2743; the document has been updated with this > zhou> reference. > > > > -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
_______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
