Subject: [abfab] #2: Section 1.4 - No discussion of transport GSS-API is running over

From: "abfab issue tracker" <[email-masked]>
Date: Fri, 09 Dec 2011 06:47:26 -0000

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

-- 
--------------------------------+-------------------------------------
 Reporter:  ietf@…              |      Owner:  draft-ietf-abfab-arch@…
     Type:  defect              |     Status:  new
 Priority:  major               |  Milestone:
Component:  arch                |    Version:
 Severity:  Active WG Document  |   Keywords:
--------------------------------+-------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/abfab/trac/ticket/2>
abfab <http://tools.ietf.org/abfab/>

---

From: Nico Williams <[email-masked]>
Date: Fri, 9 Dec 2011 11:25:08 -0600

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

---

From: "Jim Schaad" <[email-masked]>
Date: Fri, 9 Dec 2011 11:34:28 -0800

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-masked] [mailto:[email-masked]] On Behalf
> Of Nico Williams
> Sent: Friday, December 09, 2011 9:25 AM
> To: [email-masked]
> Subject: Re: [abfab] #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-masked]
> https://www.ietf.org/mailman/listinfo/abfab

---

From: Nico Williams <[email-masked]>
Date: Fri, 9 Dec 2011 14:01:33 -0600

> 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-AP…

It's not incorrect though: GSS per-message tokens do in fact form a
secure channel/transport.  That's often (but not always) not as
convenient as TLS, and for some mechanisms (e.g., ones based on bearer
tokens), not secure.

> 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 tra…

Sure.  I don't mind some text to this effect in the architecture
document, but it feels a lot like an update to RFC2743.

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Fri, 09 Dec 2011 16:04:06 -0500

>>>>> "Jim" == Jim Schaad <[email-masked]> writes:

    Jim> Additionally we may want to specify that the transport has some
    Jim> properties - such as channel binding - that may or may not be
    Jim> of interest.  What are the issues of using a non-secure vs a
    Jim> secure transport and so forth.

I can't think of any such properties, which is not to object simply to
state my current thinking.

We definitely do not want to require channel binding.

---

From: "abfab issue tracker" <[email-masked]>
Date: Sun, 11 Dec 2011 02:58:58 -0000

Comment (by ietf@…):

 Sam suggested a referene to 2743 might satisfy this.

 I think this is probably the case, but a more detailed reference than just
 the document would be needed.

 Current requirements (per sam)

 The application must transport the context tokens in order otherwise the
 authentication will fail.

 There are other implicit requirements like messages that are not received
 cannot be processed.

 RFC 2743 talks a bit about potential token sizes and I guess that might be
 an issue.

-- 
--------------------------------+--------------------------------------
 Reporter:  ietf@…              |       Owner:  draft-ietf-abfab-arch@…
     Type:  defect              |      Status:  new
 Priority:  major               |   Milestone:
Component:  arch                |     Version:
 Severity:  Active WG Document  |  Resolution:
 Keywords:                      |
--------------------------------+--------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/abfab/trac/ticket/2#comment:1>
abfab <http://tools.ietf.org/abfab/>