Structure of the Generic Security Service (GSS) Negotiation Loop
draft-ietf-kitten-gss-loop-05

Note: This ballot was opened for revision 04 and is now closed.

(Stephen Farrell) Yes

(Jari Arkko) No Objection

(Alia Atlas) No Objection

(Benoît Claise) No Objection

(Spencer Dawkins) No Objection

(Adrian Farrel) No Objection

(Joel Jaeggli) No Objection

Barry Leiba No Objection

(Kathleen Moriarty) No Objection

Comment (2015-02-17 for -04)
No email
send info
Thanks for your work on this draft.  I can see that this is just grouping text from previous RFCs to put it all in one place so the security practices in play may have been fine at time.

Was there any discussion about fixing the following from the Security Considerations section, so at least an error could be triggered?  This seems like a bigger issue with the GSS-API than one specific to this draft, so this is just a question to understand where this is at.

   The GSS-API uses a request-and-check model for features.  An
   application using the GSS-API requests certain features
   (confidentiality protection for messages, or anonymity), but such a
   request does not require the GSS implementation to provide that
   feature.  The application must check the returned flags to verify
   whether a requested feature is present; if the feature was non-
   optional for the application, the application must generate an error.
   Phrased differently, the GSS-API will not generate an error if it is
   unable to satisfy the features requested by the application.

(Martin Stiemerling) No Objection