headers
Sam Hartman | 13 Feb 2010 01:34
Picon
Favicon

Proposed bar BOF on federated authentication for non-web applications at IETF 77


I've been working with JaNet(UK) on providing a federation solution for
client applications such as mail readers, filesystem clients,
XMPP clients and the like.  There are fairly good solutions such as Open
ID, Information Card and SAML for web applications.  Within an
enterprise, you have Kerberos.  

JaNet(UK) runs one of the world's largest SAML federations.  As their
customers are beginning to take advantage of federated access for web
applications they are also asking how they can gain the same flexibility
for client-server applications.  This customer demand appears to have
traction across the entire European academic community.  I suspect that
it may find traction within enterprises and other environments.

We'd like to have a bar BOF at IETF 77 in California with a goal of an
actual BOF this summer in Europe at IETF 78.  We invite you to join our
mailing list at
https://www.jiscmail.ac.uk/cgi-bin/webadmin?A0=moonshot-community  where
we can discuss timing.

We plan to discuss the general problem and a proposed solution at the
bar BOF.  I've already prepared a feasibility analysis for JaNet(UK)'s
solution; the analysis does discuss the problem some, gives an outline
of the solution and discusses technical issues and required standards
work in detail.  By IETF we'll have a use case paper, an internet draft
on the solution,and a slide set.

we look forward to your input.  You can find a bit more detail on my
blog at http://www.painless-security.com/blog/2010/02/12/moonshot1 
You can find the feasibility analysis at
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alan DeKok | 24 Feb 2010 10:30
Favicon
Gravatar

Call for agenda items

  We have a 1 hour slot on Wednesday.  We currently have a few agenda
items, and want to ensure we don't miss any.

  Please send agenda requests to Joe && myself.

  Alan DeKok.
Permalink | Reply | 10 comments |
headers
Joseph Salowey (jsalowey | 2 Mar 2010 06:52
Picon
Favicon

Tunnel Method Requirements - mandatory attributes

Alan commented that section 4.3.3 dealing with mandatory attributes
should better define what is meant by mandatory attributes.  I agree
with this.  Alan provided some text which describes behavior that may be
too specific for a requirements document.  For example, I'm not sure it
is appropriate for a NAK to result in a failed authentication in all
cases. Alan's text is copied below.  Are folks happy with this text or
is there other specific text that should go in this document.  

" 4.3.3.  Mandatory and Optional Attributes

   The payload MUST support marking of mandatory and optional
   attributes, as well as a "NAK" attribute used to communicate
   disagreements about received attributes.

   Mandatory attributes are attributes that a receiver MUST process as
   per the specification.  Optional attributes are attributes that a
   receiver MAY ignore.

   A receiver MUST process mandatory attributes before optional ones.
   After an attribute has been processed, it SHOULD be marked as no
   longer being mandatory.  If a receiver does not process a mandatory
   attribute, it MUST ignore everything else in a request, and it MUST
   send a NAK attribute in response.  Similarly, if a receiver expects
   a mandatory attribute and does not receive one in a request, it MUST
   send a NAK attribute in the response that contains the set of
   attributes it expected to receive.

   A peer that either sends or receives a NAK attribute MUST treat
   the session as failing authentication.
(Continue reading)

Permalink | Reply | 6 comments |
headers
Joseph Salowey (jsalowey | 2 Mar 2010 06:52
Picon
Favicon

Tunnel method requirements: evaluation of protocol requirements

In his review Dan Harkins stated that he feels that section 4.1.2, Draw
from Existing Work, does not belong in the document since it is not a
technical requirement, but rather something that should be arrived at
through the working group process. This section does seem a little out
of place compared to the rest of the document.  

Since there has been no discussion on the list I am not sure where the
working group is on this issue.  Are people OK with removing section
4.1.2?  

Thanks,

Joe
Permalink | Reply | 2 comments |
headers
Joseph Salowey (jsalowey | 2 Mar 2010 06:52
Picon
Favicon

Re: review of draft-ietf-emu-eaptunnel-req-04

Thanks Dan,

I haven't seen any responses on the list yet so I provided some inline
below. 

> -----Original Message-----
> From: emu-bounces <at> ietf.org [mailto:emu-bounces <at> ietf.org] On Behalf Of
Dan
> Harkins
> Sent: Monday, November 30, 2009 12:57 PM
> To: emu <at> ietf.org
> Subject: [Emu] review of draft-ietf-emu-eaptunnel-req-04
> 
> 
>   Hello,
> 
>   I made some of these comments at the mic in Hiroshima but was
> asked to submit them to the list.
> 
>   - I get the feeling that this document is being written to
>     ensure some end-game and not simply as a protocol requirements
>     document.
> 
>     I mentioned that it would be nice if the tunneled method
>     described a way to establish an EAP-TLS -style connection,
>     either anonymous or server-side-auth-only, and then allow
>     for subsequent authentication using another EAP method (or
>     using specific TLVs for some password authentication) or
>     EAP methods chained together by the tunnel. Pasi said that
>     is the intention but it sure doesn't seem that way.
(Continue reading)

Permalink | Reply | 14 comments |
headers
Hoeper Katrin-QWKN37 | 2 Mar 2010 15:38

Re: Tunnel Method Requirements - mandatory attributes

I am happy with Alan's proposed text except for the paragraph:

"A peer that either sends or receives a NAK attribute MUST treat the
session as failing authentication."

I suggest deleting this sentence and adopt the rest of the text.

Best regards,
Katrin

> -----Original Message-----
> From: emu-bounces <at> ietf.org [mailto:emu-bounces <at> ietf.org] On Behalf Of
> Joseph Salowey (jsalowey)
> Sent: Monday, March 01, 2010 11:53 PM
> To: emu <at> ietf.org
> Subject: [Emu] Tunnel Method Requirements - mandatory attributes
> 
> Alan commented that section 4.3.3 dealing with mandatory attributes
> should better define what is meant by mandatory attributes.  I agree
> with this.  Alan provided some text which describes behavior that may
be
> too specific for a requirements document.  For example, I'm not sure
it
> is appropriate for a NAK to result in a failed authentication in all
> cases. Alan's text is copied below.  Are folks happy with this text or
> is there other specific text that should go in this document.
> 
> " 4.3.3.  Mandatory and Optional Attributes
> 
>    The payload MUST support marking of mandatory and optional
(Continue reading)

Permalink | Reply | 5 comments |
headers
Hoeper Katrin-QWKN37 | 2 Mar 2010 15:52

Re: Tunnel method requirements: evaluation of protocolrequirements

For folks not that familiar with the draft, Section 4.1.2 does not
describe existing work but rather recommends given preference to an
existing tunnel method meeting the requirements over a new method.

I personally agree with that statement but am not sure whether we need
to have this statement in the draft or if a group consensus on this is
sufficient. In general, it seems to be better to have some "proof" of a
group consensus for future discussions, e.g., when some people have
forgotten all about it ;) 

Section 4.1.2:
"Several existing tunnel methods are already in widespread usage:
EAP-FAST [RFC4851], EAP-TTLS [RFC5281], and PEAP.  Considerable
experience has been gained from various deployments with these methods.
This experience SHOULD be considered when evaluating tunnel methods.  If
one of these existing tunnel methods can meet the requirements contained
in this specification then that method SHOULD be preferred over a new
method.

Even if minor modifications or extensions to an existing tunnel method
are needed, this method SHOULD be preferred over a completely new method
so that the advantage of accumulated deployment experience and security
analysis can be gained."

Katrin
> -----Original Message-----
> From: emu-bounces <at> ietf.org [mailto:emu-bounces <at> ietf.org] On Behalf Of
> Joseph Salowey (jsalowey)
> Sent: Monday, March 01, 2010 11:53 PM
> To: emu <at> ietf.org
(Continue reading)

Permalink | Reply | 1 comment |
headers
Hoeper Katrin-QWKN37 | 2 Mar 2010 16:03

Re: review of draft-ietf-emu-eaptunnel-req-04

Dan,

The current text allows server-side only authentication for the tunnel,
i.e. the peer can remain anonymous during that phase and only transmit
its credential inside the tunnel. This enables peer privacy.

I think what you are talking about is mutually anonymous tunnels, i.e.
both peer and server remain anonymous during the tunnel establishment.
These types of tunnels are prone to man-in-the-middle attacks in which
the privacy of both tunnel endpoints is compromised. I don't see any
value of those anonymous tunnels. In fact they are not secure.

I strongly oppose to allowing these tunnels and believe that the current
text about this topic should be kept as is.

Best regards,
Katrin

PS: Details on the mentioned MitM attacks are in
http://portal.acm.org/citation.cfm?id=1577285

> -----Original Message-----
> From: emu-bounces <at> ietf.org [mailto:emu-bounces <at> ietf.org] On Behalf Of
> Joseph Salowey (jsalowey)
> Sent: Monday, March 01, 2010 11:53 PM
> To: Dan Harkins; emu <at> ietf.org
> Subject: Re: [Emu] review of draft-ietf-emu-eaptunnel-req-04
> 
> Thanks Dan,
>
(Continue reading)

Permalink | Reply | 13 comments |
headers
hzhou | 2 Mar 2010 16:08
Picon
Favicon

Re: Tunnel Method Requirements - mandatory attributes

I agree with deleting this sentence, as in some case, sending a NAK does not
necessary mean the authentication is failing.

I also recommend to remove paragraph 3, " A receiver MUST process mandatory
attributes....". It seems to be describing the protocol behavior, not a
requirement.

On 3/2/10 9:38 AM, "Hoeper Katrin-QWKN37" <khoeper <at> motorola.com> wrote:

> I am happy with Alan's proposed text except for the paragraph:
> 
> "A peer that either sends or receives a NAK attribute MUST treat the
> session as failing authentication."
> 
> I suggest deleting this sentence and adopt the rest of the text.
> 
> Best regards,
> Katrin
> 
>> -----Original Message-----
>> From: emu-bounces <at> ietf.org [mailto:emu-bounces <at> ietf.org] On Behalf Of
>> Joseph Salowey (jsalowey)
>> Sent: Monday, March 01, 2010 11:53 PM
>> To: emu <at> ietf.org
>> Subject: [Emu] Tunnel Method Requirements - mandatory attributes
>> 
>> Alan commented that section 4.3.3 dealing with mandatory attributes
>> should better define what is meant by mandatory attributes.  I agree
>> with this.  Alan provided some text which describes behavior that may
> be
(Continue reading)

Permalink | Reply | 0 comments |
headers
hzhou | 2 Mar 2010 16:16
Picon
Favicon

Re: Tunnel method requirements: evaluation of protocolrequirements

I agree to leave this in, a way to capture work group consensus. NEA
Requirement RFC (RFC5209) has similar language.

On 3/2/10 9:52 AM, "Hoeper Katrin-QWKN37" <khoeper <at> motorola.com> wrote:

> For folks not that familiar with the draft, Section 4.1.2 does not
> describe existing work but rather recommends given preference to an
> existing tunnel method meeting the requirements over a new method.
> 
> I personally agree with that statement but am not sure whether we need
> to have this statement in the draft or if a group consensus on this is
> sufficient. In general, it seems to be better to have some "proof" of a
> group consensus for future discussions, e.g., when some people have
> forgotten all about it ;)
> 
> Section 4.1.2:
> "Several existing tunnel methods are already in widespread usage:
> EAP-FAST [RFC4851], EAP-TTLS [RFC5281], and PEAP.  Considerable
> experience has been gained from various deployments with these methods.
> This experience SHOULD be considered when evaluating tunnel methods.  If
> one of these existing tunnel methods can meet the requirements contained
> in this specification then that method SHOULD be preferred over a new
> method.
> 
> Even if minor modifications or extensions to an existing tunnel method
> are needed, this method SHOULD be preferred over a completely new method
> so that the advantage of accumulated deployment experience and security
> analysis can be gained."
> 
> Katrin
(Continue reading)

Permalink | Reply | 0 comments |

Gmane