Subject: Re: [abfab] Review on gss-eap-03

From: Alejandro Perez Mendez <[email-masked]>
Date: Wed, 02 Nov 2011 14:08:31 +0100

Hi Sam,

I also performed a review of the -03 version of the draft. Thought many 
of the comments were already pointed out by Jim and solved in -04 
version, some of them are still valid. Most of them are typos or 
clarifications. I hope the will help.

Section 1.2

  * "In this case, the GSS-API peer acts..:"    s/GSS-API peer/GSS-API
    acceptor/

Section 3.1

  * Related with the GSS_C_NT_HOSTBASED_SERVICE name, I think the
    textual representation should be "SERVICE@HOST" instead of
    "HOST@SERVICE".
  * In the sentence "but the semantics are not similar enough semantics
    to use..." the second "semantics" is redundant

Section 3.3

  * Surround with () the reference in the sentence "..unless the
    acceptor supplies the acceptor name response Section 5.4.3.".

Section 5

  * Change "The innerToken field starts with a 16-bit network byte order
    token type." with "The innerToken field starts with a 16-bit network
    byte order token type identifier." to be consistent with the table.
  * In the figure describing the structure of the inner token, it may
    not be clear if Position is given in bits or bytes (not that in the
    parragraph above it talks about a 16-bit field, not a 2-byte field.

Section 5.2

  * It is stated that "The subtoken type MUST be unique within a given
    token". Is there any requirement or motivation for this? Won't this
    limit us in the future for extensions? Just asking, cause I don't
    really know.

Section 5.4

  * If the optimization related with the discussion "GSS-EAP: do we need
    an identity request" is specified, the text should be changed to
    reflect the fact that the acceptor response when in Initial State
    may not be an EAP request/identity message, but an EAP request
    starting a specific EAP method.

Section 5.4.3

  *      Change "Typically this token would only be send if" with
    "Typically this token would only be sent if"
  *      Change "If the initiator receivs an EAP Success message," with
    "If the initiator receives an EAP Success message"
  *      Change "then the acceptor sends this in the Eap Request
    subtoken type" with "then the acceptor sends this in the EAP Request
    subtoken type"
  *      What happens when none of the initiator supplied target names
    are applicable? An error is produced, or a name out of the proposed
    list is given? If this last case applies, then the text should be
    modified to reflect this fact.

Section 5.5

  * In the sentence "If the EAP state machine generates an EAP success
    message, then EAP believes the authentication is successful.", did
    you mean "If the EAP state machine generates an EAP success message,
    then EAP authenticator believes the authentication is successful."?
  * There is an inconsistence between the text in the first bullet and
    the text in the second bullet. In the first one, it talks about the
    EAP state machine generating EAP messages. Opposite, the second one
    talks about the acceptor receiving EAP messages. Though I understand
    they both are correct, I think it would be better to homogeneize
    and, in the fist bullet say: "If the acceptor receives an EAP
    success message.....".
  * Additionally, in the second bullet it is stated that an error
    subtoken is sent, and GSS failure is returned. However, in the third
    bullet it is stated that a subtoken is returned. The use of "send"
    and "return" may result a bit confusing. I think that we may want to
    homogenize this and assume that tokens are sent while GSS errors are
    returned.

Section 5.6.2

  * Nothing is said about the key to be used (I guess it will be the CRK
    described in section 6).

Section 5.7

  * I have a question here, not an issue, I'm just curious. If the
    PROT_READY is never available and per-message security services
    cannot be used before context establishment, how do you call to
    GSS_Wrap and GSS_GetMIC to generate the Channel Bindings and MIC
    subtokens?

Section 6

  * s/following procedur/following procedure/

Best regards,
Alejandro

El 01/11/11 02:11, Jim Schaad escribió:
>
>> -----Original Message-----
>> From: Sam Hartman [mailto:[email-masked]]
>> Sent: Sunday, October 30, 2011 4:20 PM
>> To: Jim Schaad
>> Cc: [email-masked]; [email-masked]
>> Subject: Re: [abfab] Review on gss-eap-03
>>
>>>>>>> "Jim" == Jim Schaad<[email-masked]>  writes:
>>
>>      Jim>  Is the ABNF for "name" still wrong?
>>
>> I don't think so.
>> What problem or oddity do you see?
>> Hmm.
>> I see that realm is only permitted if host is present. I think I've fixed
> that.
>> I think it's correct now in 04.
> That was the specific error that I saw.
>
>>
>>      Jim>  section 3.4 missing
>>
>>      Jim>  Section 4 - does/should the application get any control ovret
>>      Jim>  the set of allowable EAP methods to be used or is that purely a
>>      Jim>  fucntion of your GSS-API library
>>
>> Currently no mechanism is provided for an application to enfluence this.
>> A mechanism probably should have system-level policy configuration.
>> A mechanism could expose a credential option on the initiator.
>> If we ever need to standardize a credential option we can, but I don't see
> a
>> need for that now.
>>
>>
>>
>>      Jim>  For consistency the paragraph: Tokens from the initiator to
>>      Jim>  acceptor use an outer token type of 06 01; tokens from acceptor
>>      Jim>  to initiator use an outer token type of 06 02.  These token
>>      Jim>  types are registered in the registry of RFC 4121 token types;
>>      Jim>  see Section 8.1.
>>
>> My understanding is that the ID describes which type of token (token
>> type) we are dealing with.
>> So, I've phrased it as token s with from acceptor to initiator use  an
> inner
>> token type with ID xxx.
>> 1) token type with ID
>> and 2) inner not outer
> Looks fine
>
>>      Jim>  should refer to the "token ID" rather than the "outer token
>>      Jim>  type" either that or the item in the table should be updated.
>>
>>      Jim>  section 5.2 refers to "token type" - I think that maybe this is
>>      Jim>  the most constant phrase to be used.
>>
>> I've updated the registry to talk about token type identifiers.
>>
>>      Jim>  I will say that this version did harmonize and make the token
>>      Jim>  naming scheme much more consistent and readable.  I think this
>>      Jim>  is a big improvement.
>> Great!
>>
>>      Jim>  s/secondsubtoken/second subtoken/ (in the table)
>>
>>      Jim>  Section 5.3 - Is there going to be a rule that you should send
>>      Jim>  two error subtokens in the even t\the length is greater than 8?
>>      Jim>  I can understand saying you should ignore the extended bytes
>>      Jim>  but should you really ignore the error code itself?
>>
>> In 04 we have initiators MUST ignore octets beyond the GSS EAP error code
>> for future extensibility.  Thanks for the catch.
>>
>>      Jim>  Section 5.4 - you have different names for the acceptor name
>>      Jim>  subtokens in the description of what is permitted and the
>>      Jim>  actual subtoken names - I think you might want to harmonize
>>      Jim>  this.
>>
>>      Jim>  Is there a rason that the EAP request subtoken is not
>>      Jim>  documented in section 5.4 since it is a required subtoken from
>>      Jim>  in the Initial State message from the acceptor?
>>
>> I've added a reference. However I think it's better to document EAP
> request
>> and response near each other.
>> Note that if we adopt the proposal to reduce a round trip this subtoken
> goes
>> away from initial state.
>>
>>      Jim>  Section 5.4.1 - I realize this is a debugging string (Vender
>>      Jim>  Subtoken) but is there any reason in this day and age not make
>>      Jim>  it a UTF8 string?  (Other than it is not one for Kerbros)
>>
>> It doesn't exist for Kerberos (which has no vendor string I'm aware of) so
> I
>> don't think that's a concern.
>>
>> I've made it UTF-8; I don't care.
>>
>>      Jim>  Section 5.4.3 - Should something be said about what the
>>      Jim>  acceptor should do if the initiator sends an acceptor name
>>      Jim>  which is not completely correct for the specific acceptor.  I
>>      Jim>  am thinking specifically of things like adding a host name or
>>      Jim>  adding some service specifics to the acceptor name.  Is this
>>      Jim>  permitted?  Or is this and error condition or since this is
>>      Jim>  typically not sent is the acceptor name from the client to be
>>      Jim>  used in all events. (unless totally wrong)
>>
>> I think you mean 5.4.2 not 5.4.3?
>> My assumption is that you need to send a superset of what the acceptor
>> expects, else things will fail at channel binding. I think you want to
> leave it to
>> channel binding to fail unless an IDP wants to implement  some form of
>> aliasing.
> In 5.4.2 s/hosntame/hostname/
>
> I meant 5.4.3 - because I was assuming this was an Acceptor error rather
> than an Initiator.  That is if the Acceptor name is not a superset then it
> would return an error.  The question is should you both error and return the
> response in some sense.
>
> One possibility is that the Initiator sends name #1, the Acceptor replies
> with name #2 and then the intiator says that this is acceptable and sends
> name #2 as part of the channel binding.    In this case the was no error but
> the initator name is not a superset of the acceptor name that came back.
>
>>
>>
>>      Jim>  para #2 s/this token/This token/
>>
>>      Jim>  Section 5.5 s/ACCEPTOR/acceptor/
> Not fixed
>
>>      Jim>  The first bullet of this section is causing me some mental
>>      Jim>  problems.  The acceptor cannot confirm that the protected
>>      Jim>  result and the final result are consistent - this is hidden
>>      Jim>  from the acceptor.  --- or you need to be passing the protected
>>      Jim>  result as a RADIUS attribute, at which point it is not really
>>      Jim>  protected anymore.
>>
>> For combined authenticators the acceptor can and should evaluate the
>> protected result.
>> For pass-through authenticators the acceptor should confirm there's AAA
>> success if there is EAP success.
> Ok - I think this is more clear now.
>
>>      Jim>  The acceptor can confirm that a key has been delivered to it,
>>      Jim>  but it does not know the source of the key - i.e. was it
>>      Jim>  derived or just transmitted inside of the EAP session.
>>
>> Here, we mean the security claim discussed in section 7.10 of RFC 3748,
> which
>> probably includes transmitting a key.
>> Their term, not mine.
>> I've added a reference.
>>
> Ok
>
>>
>>      Jim>  Should the acceptor or the initiator send the error subtoken -
>>      Jim>  or should the acceptor be looking for clear EAP messages and
>>      Jim>  generate a failure?
>>
>> I don't understand.
>>
>>      Jim>  I think you need to carefully re-read the section and verify
>>      Jim>  that you think it is correct.
>>
>> I think it is consistent with what EAP does and what our implementation
>> does.
>> There are some disadvantages to how EAP handles failures.
>> We can discuss at IETF 82 if you like.
> I think this would probably be a good idea - just so I can be sure that we
> understand each other and what the doc says.
>>      Jim>  Setion 5.6 - Please tell me which type of channel binding I am
>>      Jim>  getting at this point. (I know it is GSS-API channel binding,
>>      Jim>  but given that two different types are discussed in the
>>      Jim>  document I think being explcit would be good.)
>>
>> Also added a forward reference.
>>
>>      Jim>  Section 6 - Is the KMSK in the "Tn = " line supposed to be
>>      Jim>  GMSK?
>> Yes.
>>
>>
>>      Jim>  Section 6.1 - I am unclear what the extension option field is
>>      Jim>  referring to please clarify.
>>
>> This was all wrong and has been fixed. Thanks for the reality check.
>
> _______________________________________________
> abfab mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/abfab