headers
Stephen McCann | 1 Jun 2010 14:52
Picon

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

Alan,
       I've reviewed this document and it appears fine to me.

Couple of small comments:

1) Can a reference be made to the definitions of "good", "strong" and
"weak", regarding cryptographic strength; although section 6.1 does
define "weak" quite well.

2) Within sections 4.2.1.1.2 amd 4.2.1.1.3, its not immediately clear
what "one mandatory" is referring to. Is this a "mandatory algorithm"
or a "mandatory feature"? It could perhaps do with a little
clarification.

Kind regards

Stephen McCann

On 20 May 2010 15:33, Alan DeKok <aland <at> deployingradius.com> wrote:
>  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.
>
(Continue reading)

Permalink | Reply | 2 comments |
headers
Sam Hartman | 15 Jun 2010 21:29
Picon
Favicon

Channel Binding Discussion at IETF 77


Hi.  At IETF 77, I agreed to edit draft-ietf-emu-chbind.  Also, at that
meeting, I sat down with Glen to understand his concerns with the
document.  I'd like to write up my notes on that meeting and to discuss
what I think the critical next steps are for the document.

I presented two motivating examples, one of which is I think directly
within the previous discussions of channel binding and one of which is
my motivation for caring about the problem.

Consider a corporation that has an internal network and that also has
agreements with WIFI hotspots to provide its employees connectivity.
Policy requires that people use a different set of firewall rules and
VPN configuration when connecting at the WIFI hotspots than when
connecting to the home network.  Typically clients determine which
network is in use by the SSID.  They use the same EAP credentials in
both cases.

You can imagine  that the corporation would know the identities of its
own access points.  In particular, a combination of configuration on the
AAA servers and at the boundary firewall could mean that the AAA servers
know whether a given request for access is coming from the corporate
network or a WIFI hotspot.  Today, however, the corporate AAA
infrastructure does not know what the client thinks it is connecting
to.  If the client disclosed the SSID it sees then the corporation would
be in a position to enforce the security policy.

Glen agreed that channel binding could address this.  We'll come back to
whether  it's a good idea in a bit.
(Continue reading)

Permalink | Reply | 24 comments |
headers
Joseph Salowey (jsalowey | 16 Jun 2010 00:34
Picon
Favicon

Re: Channel Binding Discussion at IETF 77

Hi Sam,

Thanks again for taking this on.  I think the approach below makes
sense.  I think one of the biggest sticking points has been around the
motivation and use cases.  I believe this has been holding up progress
more than anything else.  The next big issue has been around the
requirements for the bindings themselves and how they should be
designed.  The draft mainly focuses on these aspects.  

I think we've had pretty good agreement that we would like to have a
common names space for bindings so we don't have different methods doing
different things.  I think a tunnel method approach could be useful
here; we have had some discussion of this and I think we will have more
as we move further along in tunnel method development.   We had
previously deferred a concrete definition of channel bindings to a
follow-on document; I think some people would like to see the current
document include this as well.  

I'll go back and check to see what other issues are open, but I think
what you discuss below involves most of the large open issues.  Do you
think you can have a revision in time for discussion in Maastricht?

Cheers,

Joe 

> -----Original Message-----
> From: emu-bounces <at> ietf.org [mailto:emu-bounces <at> ietf.org] On Behalf Of
Sam
> Hartman
(Continue reading)

Permalink | Reply | 2 comments |
headers
Sam Hartman | 16 Jun 2010 15:14
Picon
Favicon

Re: Channel Binding Discussion at IETF 77

I will definitely have a revision for IETF 78.  I may not have
everything I'd like to have done ready for that revision.
Permalink | Reply | 1 comment |
headers
Sam Hartman | 16 Jun 2010 22:30
Picon
Favicon

Federated Authentication BOF at IETF 78


Hi.  I'd like to announce that there will be a BOF on federated
authentication beyond the web at IETF 78.  we'd like to form a working
group to standardize protocols for federated access to applications that
are not browser based.  Targets include think client applications and
some machine-to-machine authentication use cases.  At this point we have
not focused on requirements imposed by RAI applications.

You can see draft specs at
http://www.project-moonshot.org/specifications 
There is a BOF agenda at http://www.project-moonshot.org/bof/agenda 

We encourage you to join our mailing list, see
http://jiscmail.ac.uk/cgi-bin/webadmin?LIST=MOONSHOT-COMMUNITY .  To the
extent we're able we'd love to collect comments or things people will
want to discuss at the BOF now.  Hopefully we can get as much as
possible out of the way on the list and have a very productive session!
We hope to see you there.
Permalink | Reply | 0 comments |
headers
Stephen McCann | 17 Jun 2010 01:22
Picon

Re: Channel Binding Discussion at IETF 77

Sam, Joe,
                I think the tunneled approach is a good concept and
allows extensibility.

However, I'd also like to encourage the creation of an updated
document for the July meeting, sounds a good move forward.  I'm
certainly willing to review such a revision.

Kind regards

Stephen

On 16 June 2010 08:14, Sam Hartman <hartmans-ietf <at> mit.edu> wrote:
> I will definitely have a revision for IETF 78.  I may not have
> everything I'd like to have done ready for that revision.
> _______________________________________________
> Emu mailing list
> Emu <at> ietf.org
> https://www.ietf.org/mailman/listinfo/emu
>
Permalink | Reply | 0 comments |
headers
Joseph Salowey (jsalowey | 17 Jun 2010 07:17
Picon
Favicon

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

Hi Stephen,

Thanks for the review.  Comments inline below:

> -----Original Message-----
> From: emu-bounces <at> ietf.org [mailto:emu-bounces <at> ietf.org] On Behalf Of
> Stephen McCann
> Sent: Tuesday, June 01, 2010 5:53 AM
> To: emu <at> ietf.org
> Subject: [Emu] LAST CALL: draft-ietf-emu-eaptunnel-req-06.txt
> 
> Alan,
>        I've reviewed this document and it appears fine to me.
> 
> Couple of small comments:
> 
> 1) Can a reference be made to the definitions of "good", "strong" and
> "weak", regarding cryptographic strength; although section 6.1 does
> define "weak" quite well.
> 
[Joe] I think most places where we use the word strong or good it doesn't add anything so it can be removed and
other places it can refer to section 6.1.  I'll go through the document and fix these. 

> 2) Within sections 4.2.1.1.2 amd 4.2.1.1.3, its not immediately clear
> what "one mandatory" is referring to. Is this a "mandatory algorithm"
> or a "mandatory feature"? It could perhaps do with a little
> clarification.
> 
[Joe] The intent is to say require implementations to provide a common set of algorithms that meet a minimum
set of requirements.  A TLS cipher suite is a set of algorithms so a mandatory to implement cipher suite is a
(Continue reading)

Permalink | Reply | 1 comment |
headers
Stephen McCann | 17 Jun 2010 14:23
Picon

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

Joe,
       clarifications are good. Thanks.

Kind regards

Stephen

On 17 June 2010 00:17, Joseph Salowey (jsalowey) <jsalowey <at> cisco.com> wrote:
> Hi Stephen,
>
> Thanks for the review.  Comments inline below:
>
>> -----Original Message-----
>> From: emu-bounces <at> ietf.org [mailto:emu-bounces <at> ietf.org] On Behalf Of
>> Stephen McCann
>> Sent: Tuesday, June 01, 2010 5:53 AM
>> To: emu <at> ietf.org
>> Subject: [Emu] LAST CALL: draft-ietf-emu-eaptunnel-req-06.txt
>>
>> Alan,
>>        I've reviewed this document and it appears fine to me.
>>
>> Couple of small comments:
>>
>> 1) Can a reference be made to the definitions of "good", "strong" and
>> "weak", regarding cryptographic strength; although section 6.1 does
>> define "weak" quite well.
>>
> [Joe] I think most places where we use the word strong or good it doesn't add anything so it can be removed and
other places it can refer to section 6.1.  I'll go through the document and fix these.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Yaron Sheffer | 18 Jun 2010 12:31
Picon

Re: Channel Binding Discussion at IETF 77

Hi Sam,

I am glad you are taking a fresh look at this issue. Some comments:

- I think draft-ietf-emu-chbind is not as interesting, or potentially 
useful, as draft-clancy-emu-aaapay. In any case, both drafts should be 
looked at together.

- I think tunnel methods are more trouble than they're worth in this 
context. They create inter-layer security issues of their own. And most 
people tend to think of TLS+PKI when talking about tunnel methods, even 
though theoretically there may be alternatives.

- I support very much the need to standardize channel binding 
attributes. There are EAP methods today with a placeholder for such 
attributes (EAP-GPSK, EAP-EKE, probably more).

- In addition to attributes, I think (or rather, I'm afraid) we need to 
standardize/recommend a minimal set of such attributes for some use 
cases. For example, in a wi-fi setting you can expect to receive an IP 
address (MAC address?) and an SSID. I realize this can turn into a major 
rathole but without such recommendations, there are too many possible 
combinations.

Thanks,
	Yaron

> ----------------------------------------------------------------------
>
> Message: 1
(Continue reading)

Permalink | Reply | 0 comments |
headers
Glen Zorn | 19 Jun 2010 19:41

Re: Channel Binding Discussion at IETF 77

Sam Hartman [mailto://hartmans-ietf <at> mit.edu] writes:

> Hi.  At IETF 77, I agreed to edit draft-ietf-emu-chbind.  Also, at that
> meeting, I sat down with Glen to understand his concerns with the
> document.  I'd like to write up my notes on that meeting and to discuss
> what I think the critical next steps are for the document.
> 
> 
> I presented two motivating examples, one of which is I think directly
> within the previous discussions of channel binding and one of which is
> my motivation for caring about the problem.
> 
> Consider a corporation that has an internal network and that also has
> agreements with WIFI hotspots to provide its employees connectivity.
> Policy requires that people use a different set of firewall rules and
> VPN configuration when connecting at the WIFI hotspots than when
> connecting to the home network.  Typically clients determine which
> network is in use by the SSID.  They use the same EAP credentials in
> both cases.
> 
> You can imagine  that the corporation would know the identities of its
> own access points.  In particular, a combination of configuration on the
> AAA servers and at the boundary firewall could mean that the AAA servers
> know whether a given request for access is coming from the corporate
> network or a WIFI hotspot.  Today, however, the corporate AAA
> infrastructure does not know what the client thinks it is connecting
> to.  If the client disclosed the SSID it sees then the corporation would
> be in a position to enforce the security policy.
> 
> Glen agreed that channel binding could address this.
(Continue reading)

Permalink | Reply | 19 comments |

Gmane