Nico, I am not saying that we need to say what the transport is, but if you have a neophyte looking at the document and trying to figure out what is happening they are going to start assuming that GSS-API apparently has a transport as part of it. As we know this is incorrect.
Additionally we may want to specify that the transport has some properties - such as channel binding - that may or may not be of interest. What are the issues of using a non-secure vs a secure transport and so forth. Jim > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf > Of Nico Williams > Sent: Friday, December 09, 2011 9:25 AM > To: [email protected] > Subject: Re: [abfab] #2: Section 1.4 - No discussion of transport GSS-API is > running over > > On Fri, Dec 9, 2011 at 12:47 AM, abfab issue tracker > <[email protected]> wrote: > > #2: Section 1.4 - No discussion of transport GSS-API is running over > > > > This list of steps does not talk about the actual transport used > > between the client and the RP in any of the steps. I believe that > > this needs to be included as it is a core part of the architecture > > for an application implementor or specification writer. > > Huh? Why? Sure, we should recommend the use of TLS and channel binding > to it for new applications, but there's nothing special about ABFAB (except > for mechanisms that are too weak to use without a secure > channel) here -- this is a general recommendation worth making no matter > what the GSS mechanism that is in use. > > But also, existing applications do what they do, and it's not our place to > tell > them to do something else. We can say that some mechanism or other is not > to be used outside a secure channel. > > Nico > -- > _______________________________________________ > abfab mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/abfab _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
