Subject: [abfab] a review on draft-ietf-abfab-gss-eap-04

From: [email-masked]
Date: Fri, 16 Dec 2011 10:17:43 +0800

Hi,all, the following are questions occured to me when reading 
draft-ietf-abfab-gss-eap-04:

1. Section 1 
    "The Extensible Authentication Protocol (EAP) [RFC3748] defines a
   framework for authenticating a network access client and server in
   order to gain access to a network."
 
  since applicability of EAP is under updating beyond network access, I 
think the information of Section 7 might as well be 
indicated here.

2.  section 5.4.2 and section 5.7 
   Why would acceptor name appear in a acceptor name request?

3.  section 5.4.3 
  "Typically this token would only be send if the acceptor name request is 
absent."
   Acceptor name response is sent only when no acceptor name request has 
been received?

4. section 5.6
   "After EAP success, the initiator sends a token to the acceptor
   including additional subtokens that negotiate optional features or
   provide GSS-API channel binding (see Section 6.1)."
 
   According to RFC2743, GSS-API channel binding information is provided 
as an input to GSS_Init_sec_context(), i.e., before 
EAP sucess, so how and why send GSS-API channel binding here?

5. "The PROT_READY service is never available with this mechanism."
   what is PROT_READY service? I cann't find any reference to it.

Regards~~~

-Sujing Zhou

--------------------------------------------------------
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.

---

From: Sam Hartman <[email-masked]>
Date: Fri, 16 Dec 2011 13:38:33 -0500

>>>>> "zhou" == zhou sujing <[email-masked]> 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.

    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.

    zhou> Regards~~~

    zhou> -Sujing Zhou

    zhou> -------------------------------------------------------- ZTE
    zhou> Information Security Notice: The information contained in this
    zhou> mail is solely property of the sender's organization. This
    zhou> mail communication is confidential. Recipients named above are
    zhou> obligated to maintain secrecy and are not permitted to
    zhou> disclose the contents of this communication to others.  This
    zhou> email and any files transmitted with it are confidential and
    zhou> intended solely for the use of the individual or entity to
    zhou> whom they are addressed. If you have received this email in
    zhou> error please notify the originator of the message. Any views
    zhou> expressed in this message are those of the individual sender.
    zhou> This message has been scanned for viruses and Spam by ZTE
    zhou> Anti-Spam system.

    zhou> _______________________________________________ abfab mailing
    zhou> list [email-masked]
    zhou> https://www.ietf.org/mailman/listinfo/abfab

---

From: [email-masked]
Date: Sat, 17 Dec 2011 10:12:28 +0800

Regards~~~

-Sujing Zhou

> I'd be interested in any clarifications you can suggest so others don't
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