Re: Tunnel method requirements: Mandatory attributes

Joseph Salowey (jsalowey) wrote:
> We had some discussion of the mandatory attributes section in Anaheim.
> There was disagreement on the exact behavior of mandatory attributes.
> Instead of describing a specific behavior in the requirements document I
> think it would be better to include the requirement instead. 
> 
> Proposed modification:
> 
> Replace section " 4.3.3. Mandatory and Optional Attributes" with
> 
> "4.3.3  Indicating criticality of Attributes
> 
> It is expected that new attributes will be defined to be carried within
> the tunnel method.  In some cases it is necessary for the sender to know
> if the receiver did not understand the attribute.  To support this,
> there MUST be a way for the sender to mark attributes such that the
> receiver will indicate if an attribute is not understood.  "

Just to be clear, you're suggesting that this one paragraph replace 
all of the paragraphs in 4.3.3?

spt

Re: Tunnel method requirements: Mandatory attributes

yes

-----Original Message-----
From: Sean Turner [mailto:turners <at> ieca.com] 
Sent: Thursday, May 06, 2010 7:13 PM
To: Joseph Salowey (jsalowey)
Cc: emu <at> ietf.org
Subject: Re: [Emu] Tunnel method requirements: Mandatory attributes

Joseph Salowey (jsalowey) wrote:
> We had some discussion of the mandatory attributes section in Anaheim.
> There was disagreement on the exact behavior of mandatory attributes.
> Instead of describing a specific behavior in the requirements document
I
> think it would be better to include the requirement instead. 
> 
> Proposed modification:
> 
> Replace section " 4.3.3. Mandatory and Optional Attributes" with
> 
> "4.3.3  Indicating criticality of Attributes
> 
> It is expected that new attributes will be defined to be carried
within
> the tunnel method.  In some cases it is necessary for the sender to
know
> if the receiver did not understand the attribute.  To support this,
> there MUST be a way for the sender to mark attributes such that the
> receiver will indicate if an attribute is not understood.  "

I-D Action:draft-ietf-emu-eaptunnel-req-06.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the EAP Method Update Working Group of the IETF.

	Title           : Requirements for a Tunnel Based EAP Method
	Author(s)       : K. Hoeper, et al.
	Filename        : draft-ietf-emu-eaptunnel-req-06.txt
	Pages           : 24
	Date            : 2010-05-14

This memo defines the requirements for a tunnel-based Extensible
Authentication Protocol (EAP) Method.  This method will use Transport
Layer Security (TLS) to establish a secure tunnel.  The tunnel will
provide support for password authentication, EAP authentication and
the transport of additional data for other purposes.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-emu-eaptunnel-req-06.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

_______________________________________________
Emu mailing list
Emu <at> ietf.org

Summary of Federated Authentication BOF at IETF 77

I'm told there were around 30 people in the room.  That seemed like a
good turn out for Thursday at 9 PM.

Many of the participants had already read some or all of the proposed
documents.
I presented a problem statement based on providing federated
authentication  for non-web applications.
Two solutions were presented.  I presented work on Moonshot, a
technology that combines EAP, GSS-API, RADIUS and SAML to solve the
problem.  Eliot Lear and Klaas Wierenga presented a simpler solution
that uses browser-based SAML and Open ID.

The sense of the room was that these solutions compliment each other.
Moonshot requires more infrastructure and client configuration but
provides several advantages.  The browser-based solutions are something
that requires fewer client changes.

Volunteers were collected from the EAP, GSS and RADIUS communities who
would be interested in working on these problems.  Some of the work
discussed, possibly especially including the Open ID and SAML
browser-based solutions may be able to progress in kitten.  I and I
believe several of the other Moonshot proponents would prefer to focus
the Moonshot work in one working group.  Other solutions could also be
progressed in that group, although we should be careful not to slow down
work that could progress quickly in kitten by moving it into an
as-yet-unchartered group.

There seemed to be strong support for going forward.  However, several
things to address in a BOF were raised with regard to the Moonshot work.

Re: Summary of Federated Authentication BOF at IETF 77

Hello,

I have a comment about use of EAP in this context.

Folks might remember the ICOS BoF held during IETF 62. Discussions at that
meeting, around that era, and since then have been always pointing to the
applicability statement of EAP and more-or-less blocking the use of EAP for
anything other than network access.

EAP RFC 3748:

   EAP was designed for use in network access authentication, where IP
   layer connectivity may not be available.  Use of EAP for other
   purposes, such as bulk data transport, is NOT RECOMMENDED.

See the meeting notes at http://www.ietf.org/proceedings/62/icos.html,
especially Sam's (SEC AD at that time):

	Sam: Although having a lot of EAP methods is complicated, deploying
new credentials 
	is also hard. I think the uses of EAP that were discussed here are
close enough to 
	network access that I could see the connection. But when EAP was
expaned from PPP 
	to other uses, a lot of new work was required; if we expand EAP to
services in general, 
	we need at least the same amount of work. We might want to check
that there are 
	no better solutions. So if you're using EAP for something totally
else than 

LAST CALL: draft-ietf-emu-eaptunnel-req-06.txt

  The current version of the document has addressed all open concerns.
We will therefore be having a last call lasting for two weeks, until
June 4, 2010.

  Please take the time to review the document for any issues.  Reviews
should be posted to the list, and should contain technical and editorial
comments.

  If there are no objections, we will start the publication process.  If
all goes well, the document should be in process by the next IETF meeting.

  Alan DeKok.

Internet-Drafts <at> ietf.org wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the EAP Method Update Working Group of the IETF.
> 
> 
> 	Title           : Requirements for a Tunnel Based EAP Method
> 	Author(s)       : K. Hoeper, et al.
> 	Filename        : draft-ietf-emu-eaptunnel-req-06.txt
> 	Pages           : 24
> 	Date            : 2010-05-14
> 
> This memo defines the requirements for a tunnel-based Extensible
> Authentication Protocol (EAP) Method.  This method will use Transport
> Layer Security (TLS) to establish a secure tunnel.  The tunnel will
> provide support for password authentication, EAP authentication and
> the transport of additional data for other purposes.
> 

Re: Summary of Federated Authentication BOF at IETF 77

>>>>> "Alper" == Alper Yegin <alper.yegin <at> YEGIN.ORG> writes:

    Alper> Was this discussed? Is there a proposal to expand the
    Alper> applicability statement of EAP now? Where do we draw the new
    Alper> line now?

I've certainly been thinking about it.

Quoting http://www.painless-security.com/blog/2010/02/12/moonshot1:

>Itùs interesting that Iùm advocating EAP for application layer
>authentication. When I was a Security AD, I made a strong statement
>that EAP must only be used for network access. Iùve been fairly
>consistent about that since then. I think there are two huge problems
>with using EAP for application authentication. The first is that EAP
>only authenticates the home realm; it does not authenticate what
>service youùre going to. So you might try to connect to your
>e-mail and end up giving something access to your stored files and
>pictures instead. That is, EAP has aphishing exposure in the
>federated context. If the only thing you can get by using EAP is
>network access, that exposure is only moderate. However in a fully
>federated environment that is a huge exposure. Moonshot will address
>thisproblem by using EAP channel binding and by doing the necessary
>work to make that a viable solution. The second concern is that
>interoperability is reduced when you have multiple authentication
>approaches for the same problem. If EAP is going to be used for
>application authentication, we need to understand how it relates to
>the rest of the application authentication metasystem. Moonshot
>proposes such a relationship, addressing my objection.

Re: Summary of Federated Authentication BOF at IETF 77

> >>>>> "Alper" == Alper Yegin <alper.yegin <at> YEGIN.ORG> writes:
> 
>     Alper> Was this discussed? Is there a proposal to expand the
>     Alper> applicability statement of EAP now? Where do we draw the new
>     Alper> line now?
> 
> I've certainly been thinking about it.
> 
> Quoting http://www.painless-security.com/blog/2010/02/12/moonshot1:
> 
> >Itùs interesting that Iùm advocating EAP for application layer
> >authentication. When I was a Security AD, I made a strong statement
> >that EAP must only be used for network access. 

That's right. 

> > Iùve been fairly
> >consistent about that since then. I think there are two huge problems
> >with using EAP for application authentication. The first is that EAP
> >only authenticates the home realm; it does not authenticate what
> >service youùre going to. So you might try to connect to your
> >e-mail and end up giving something access to your stored files and
> >pictures instead. That is, EAP has aphishing exposure in the
> >federated context. If the only thing you can get by using EAP is
> >network access, that exposure is only moderate. However in a fully
> >federated environment that is a huge exposure. Moonshot will address
> >thisproblem by using EAP channel binding 

"Channel binding" is a term that is specific to the network access
application. 

Re: Summary of Federated Authentication BOF at IETF 77

>>>>> "Alper" == Alper Yegin <alper.yegin <at> yegin.org> writes:

    >> authentication. The first is that EAP >only authenticates the
    >> home realm; it does not authenticate what >service youùre
    >> going to. So you might try to connect to your >e-mail and end up
    >> giving something access to your stored files and >pictures
    >> instead. That is, EAP has aphishing exposure in the >federated
    >> context. If the only thing you can get by using EAP is >network
    >> access, that exposure is only moderate. However in a fully
    >> >federated environment that is a huge exposure. Moonshot will
    >> address >thisproblem by using EAP channel binding

    Alper> "Channel binding" is a term that is specific to the network
    Alper> access application.  For generic applications, we need
    Alper> something else. Basically we are talking about "authorization
    Alper> parameters." App server has verified that you are Joe, and
    Alper> you are allowed to use X, Y, Z apps/resources. This
    Alper> "authorization" aspect goes beyond "authentication" (as in
    Alper> extensible "authentication" protocol). This aspect may not be
    Alper> easy to stick in the EAP.

When I'm speaking of channel binding, I am not speaking of that sort of
authorization.
i'm speaking of giving the peer (not the NAS) confidence  that the peer
has connected to the NAS that the peer intended to connect to.
I argue that when you generalize the NAS so that the NAS is a mail
server, web server, or other app server, the question of which
generalized NAS you're talking to is far more important than in the
network access application.
I believe that both RFC 3748 and draft-ietf-emu-chbind define this