# TIGRESS @IETF 118 Prague, Nov 8 1200-1300 UTC   {#tigress-ietf-118-prague-nov-8-1200-1300-utc}

*   Notewell by Chairs
    *   Thank you Roman for helping move the session due to several
        conflicts.

*   Agenda : focus on discussion around security properties of the
    introduction channel

## Security Channel Presentation - Ekr   {#security-channel-presentation---ekr}

https://datatracker.ietf.org/doc/slides-118-tigress-introduction-channel-security/

Q by Yogesh : Second factor comes after the fact. Slide 8 shows that the
exchange is blocked which is not accurate.

Note by Leif: Questions after the presentation. Clarifying questions are
welcome.

Slide 10 talks about the 2 options available.   
 \* Assume the introduction channel is secure and move forward  
 \* Assume introduction channel is insecure and flesh out its security
properties.

Q by Tommy Pauly : 2 questions : First one, I have been chatting with
Dmitry/Yogesh, I want to clarify that there is an assumption that a
single person can get the credentials. Is there a way in the new
protocol to not allow the attacker to win the race multiple times?

Ekr: Fix is easy.

Tommy Pauly: Maybe add a state, cookie.  
Next question, related to second factor. It feels like overall the
second factor idea is to use the second factor channel as bootstrapping
channel. I use SMS and email, it makes it less likely for attacker to be
looking at both of them. Have the protocol define a way to split up the
secret.

Ekr: second factor channel is somewhat limited. The most plausible
option is where I call you on phone and give you the second factor.
Let's flesh out the second factor. Pin is low entropy....the problem is
complicated.

Dmitry: I probably can clarify somethings here. If we indeed have a
perfectly secure channel, we can pass the provisioning info. But when we
originally thought of this channel, balance of security and usability
was kept in mind. Risk can be mitigated by separating the intoduction
secret plus second factor. Pin retries will be limited.

Yogesh: Agree with Ekr about we do trust the channel. We also understand
that it is potentially insecure. We need to understand it from the
perspective of vertical people like car makers. We don't want to prevent
people from using the channel that they already use all the time. Also,
we have to encourage people to really use the second factor.

Christopher Wood: Q about the assumed use case, is there anything like
latency or performance req for this protocol?   
yogesh: It's fine to use 10 round trips. No notion of instantaneous.   
Chris: Option 1 seems to be clear candidate to start with. (Assume the
channel to be secure.) This will simplify the design and solve the
simple problem first.

Leif: Should we move the entire introduction channel out of scope or
just the security properties of the the channel?

Chris: Assumptions need to be in scope.

Ekr: Common ground, charter text talk about establishing the secure
channel.

Eric Kinnear: Bootstrapping of this channel is something I would like to
use but I understand if we can't because of scope. Would prefer option
2.

Simon from Mozilla : Favor of option 2: assume introduction channel is
insecure.

Tommy Pauly: I like approach of Option 1-assume intro channel is secure.
If we are splitting the scope here, what is out of scope is what is the
content of this credential body. When we are defining a cred that needs
to be tansferred, can we say that the vertical can require to have a
second factor.

Yogesh: Even if we go with option 1, its not necessarily true all the
time. I do want to put a second factor knob on.

Tommy: Assume that the introduction channel is secure enough to
understand what the credential is. Split up the problem differently.Make
the presence of second factor orthogonal.

Yogesh: Th idea that using a pin everytime is an option. Currently this
is under users control. (More details by Yogesh)

Dean Saxe from Amazon: We are maybe not looking at prior art from this
space. UMA2 can be used to delegate authority within a range of time for
some purposes.See what prior art exists and use the best practices that
we have today for second factor.

https://www.youtube.com/watch?v=0cCXJvJ6GUY&t=14s&pp=ygUOZXZlIG1hbGVyIHVtYTI%3D

https://docs.kantarainitiative.org/uma/wg/rec-oauth-uma-grant-2.0.html

Dmitry: Credential exchange and credential activation are separate.<>

Leif: Most wallet include channel bindings and it is orthogonal. It's a
little dangerous for TIGRESS to produce a separate doc on channel
binding.

Ekr: Do we believe that the info in intro channel is secure enough? If
that's true, we are good to go.

Aaron Parecki: I hear a different use everytime. I am concerned that we
are so narrowly scoped on this channel that we are ignoring other work
being done by IETF. I haven't heard that whether this is a delegation
problem or copying problem? key is different or same ?

Ekr: Broad array of existing verticals. Purpose is to facilitate the
content of a credential.  
(To be filled in with recording)

Aaron: This feels to me that we are doing a lot of reinevnting of a
channel that really already exists.

Dmitry: It's a delegation problem. In some cases an exact copy of the
key can be passed.

Yogesh: Credential could be a copy or delegation. It is an opaque blob
for this channel.

*   A Poll was conducted to get a sense of which direction the WG is
    leaning towards:

Results:  
Option 1: Assume that the Introduction Channel is secure and move
forward to protocol selection.  
Yes-8 , No-8, No Opinion-27

Option2 : Assume that the Introduction Channel is insecure and ask what
the properties of the “second factor” are.  
Yes-0, No-17, No Opinion-26

Option 3: Both, orthogonally  
Yes-12, No-4, No Opinion-28

Option 4: We need to rethink  
Yes-10, No-5, No Opinion-29