Thank you for taking a crack at the charter update Joe!
Pls find some comments inline.
Thanks,
Bart
From: Joseph Salowey <j...@salowey.net>
Date: Monday, 16 December 2024 at 07:07
To: Paresh Sawant <paresh_saw...@apple.com>
Cc: emu@ietf.org <emu@ietf.org>, Bart Brinckman (bbrinckm) <bbrin...@cisco.com>
Subject: Re: [Emu] Re: draft-sawant-eap-ppt
Sorry for the delay. The EMU charter is pretty tight so this may not be
covered, however if we agree on the problem we are trying to solve, which we
need to do anyway, then updating the charter isn't much of an issue.
Here is an initial stab at the problem
An EAP method that provides additional privacy by preventing a visited network
from knowing the identity of a user and for the home provider from tracking
what networks a specific client is using.
{BART} using home provider implies that the identity provider for this user
offers a network service. This may not be the case. Maybe following?
An EAP method that provides privacy by preventing a visited network from
knowing the identity of a user and for the identity provider of that user from
tracking what networks a specific client is using.
Some things that we are not trying to solve for:
- Providing a mechanism directly associated with the EAP method to identify a
misbehaving client so it can be excluded from the network (other information
such as MAC address is not related to this exchange and could be used)
- others?
Things that may be open issues:
- Does the visited network need to know who the home provider is? (it seems it
would be better privacy if it didn't)
{BART}: There is not a single home provider here, but rather 2 entities
involved:
1. The ‘identity provider’, in privacypass this is the attester & issuer
2. The ‘redeemer’, this is the AAA that runs EAP-PPT and verifies the token
The visited network will know who the ‘redeeming AAA’ as it will use its realm
to route the packet.
- What information does the home provider get (if any) - for example today
things like client MAC address may be sent through the AAA call chain - while
this is somewhat outside the EAP method it seems like this could negatively
impact the privacy of this use case.
{BART}: The redeeming AAA will receive this information. The identity provider
will not.
- THe client needs to get a privacy pass token over a different interface or
have tokens cached if they don't have one and need network access
Proposed mechanism
- the proposal is to use a mechanism similar to RFC 9577 as an EAP method where
the client already has a privacy pass token issued from an issuer acceptable to
the server. The server sends a challenge and the client generates an
untraceable token from the challenge and the issued token to send to the server
to verify.
Some initial comments on the document
- I dont think EAP-PPT generates key material, it requires the tunnel method to
generate key material as the privacy pass exchange does not result in shared
keys
- Since EAP-PPT does not generate keys channel binding is of limited value.
{BART}: It did not generate key material in draft-00, it does since draft-01
https://www.ietf.org/archive/id/draft-sawant-eap-ppt-01.html#name-key-material-generation
Thanks,
Joe
On Wed, Dec 11, 2024 at 9:35 PM Paresh Sawant
<paresh_sawant=40apple....@dmarc.ietf.org<mailto:40apple....@dmarc.ietf.org>>
wrote:
Hello EMU WG,
Can you please tell us the next required steps to initiate an adoption call for
EAP-PPT? We are happy to work on any feedback you have with the current draft.
Sincerely,
Paresh Sawant
On Dec 11, 2024, at 11:43 AM, Bart Brinckman (bbrinckm)
<bbrinckm=40cisco....@dmarc.ietf.org<mailto:40cisco....@dmarc.ietf.org>> wrote:
Hi EMU working group & chairs,
We did take update the draft with all the comments we received before IETF121
and did not receive any since. I do believe in order to move the draft forward
we need working group adoption and thorough review from the working group. If a
charter update is required, I am happy to help with a proposal.
Thanks,
Bart
From: Michael Richardson <mcr+i...@sandelman.ca<mailto:mcr%2bi...@sandelman.ca>>
Date: Tuesday, 3 December 2024 at 16:40
To: Eliot Lear <l...@lear.ch<mailto:l...@lear.ch>>,
emu@ietf.org<mailto:emu@ietf.org> <emu@ietf.org<mailto:emu@ietf.org>>
Subject: [Emu] Re: draft-sawant-eap-ppt
Eliot Lear <l...@lear.ch<mailto:l...@lear.ch>> wrote:
> I would like to follow-up on discussion from IETF 121. When last we left
our
> heros on EAP-PPT, the draft is in reasonable shape but there was some
> question as to whether it was within the charter. If it's not, I
> propose to
It seems in shape, and I don't understand why it wouldn't be in charter.
I would rather s/ppt/privpass/ or something. "PPT" is a too-confusing TLA,
and probably has a trademark against it.
> amend the charter to cover this draft. If it is, I propose that we adopt
> draft-sawant-eap-ppt as a working group item.
--
Michael Richardson <mcr+i...@sandelman.ca<mailto:mcr%2bi...@sandelman.ca>> .
o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
_______________________________________________
Emu mailing list -- emu@ietf.org<mailto:emu@ietf.org>
To unsubscribe send an email to emu-le...@ietf.org<mailto:emu-le...@ietf.org>
_______________________________________________
Emu mailing list -- emu@ietf.org<mailto:emu@ietf.org>
To unsubscribe send an email to emu-le...@ietf.org<mailto:emu-le...@ietf.org>
_______________________________________________
Emu mailing list -- emu@ietf.org
To unsubscribe send an email to emu-le...@ietf.org
