►
From YouTube: IETF100-ACE-20171114-0930
Description
ACE meeting session at IETF100
2017/11/14 0930
https://datatracker.ietf.org/meeting/100/proceedings/
A
Good
morning,
everyone,
this
is
the
eighth
session.
If
you
are
not
here
for
Ace
I,
probably
Rican
salt
the
agenda
and
find
a
different
groom.
We
currently
do
not
have
any
volunteers
for
minutes
or
jabber
scribe.
Do
we
have
any
volunteers?
Now
we
have
a
volunteer
for
jabber,
so
we
still
need
some
minutes
excellent.
Just
in
the
ether
pad
or
oh
no
Jay
ever
you
got
claimed.
A
B
A
A
A
Yeah,
the
mic
seemed
very
live
earlier,
so
I
was
keeping
it
far
away.
But
yes,
everyone
should
note
the
note.
Well,
it's
also
available
online.
If
you
use
your
favorite
search
tool
to
search
for
IETF
note.
Well,
you
will
find
it
so
on
to
the
next
slide
with
the
agenda.
So
we
did
make
a
couple
of
small
changes
last
night.
So
if
everyone
has
had
a
chance
to
review
the
agenda
has
proposed
changes.
Other
things
I
want
to
talk
about.
Please
come
up
to
the
microphone
now.
A
A
And
in
terms
of
document
progressing,
hopefully
everyone
saw
that
the
CWT
document
is
now
in
working
group.
Last
call
we'd
give
it
a
couple
extra
weeks,
because
the
last
call
period
does
overlap
with
both
this
meeting
and
the
US
Thanksgiving
holiday.
So
please
get
your
comments
in
by
the
29th
of
this
month.
A
C
Good
morning,
I'm
Mike
Jones
from
Microsoft
and
I'm
here
on
behalf
of
my
co
editors,
to
talk
about
two
closely
related
drafts.
The
first
is
the
Seaboard
web
token,
which
Ben
is
just
mentioning
which
is
used
by,
among
others,
a
soweth
and
some
other
work,
including
work
outside
the
ITF,
so
we're
at
draft
9.
There
was
a
first
working
group
last
call
on
draft
7
before
we
last
met
our
heroes.
C
Since
then,
what's
primarily
happened
is
people
gave
us
substantive
feedback
on
the
examples,
and
that
was
incorporated
mostly
there's
now
much
more
extensive
of
seaboard
diagnostic
notation,
the
technical
content
of
the
examples
hasn't
really
changed
other
than
we
added
key
IDs
so
that
those
could
be
referenced.
I
will
say
that-
and
this
has
happened
on
the
list,
so
you're
probably
already
aware
of
it,
but
there
have
been
multiple
independent
validations
of
the
technical
content
of
the
examples.
C
One
issue
has
been
identified
in
current
reviews.
So
far
this
may
have
been
Hannes
or
Hannes
was
a
commenter
on
this
that
the
current
language
describing
the
audience
claim
is
ambiguous.
The
intent
was
to
say
that
audience
values
are
of
type
string
or
URI,
and
it
does
say
the
structure
is
exactly
parallel
to
jot.
Where
jot
it
can
be
an
array
of
audience
values,
and
that
was
the
intent
here.
C
C
Editorial
feedback
is
always
great,
but
if
you've
built
this
and
as
you've
read
this
back,
you
came
up
with
things
that
seemed
or
you
had
to
make
a
judgment,
call
or
whatnot.
This
is
exactly
the
time
to
finish.
Making
everything
is
unambiguous,
as
possible
after
working
group
last
call
we'll
make
improvements
that
are
identified
and
hopefully
be
ready
to
request
publication,
but
that's
up
to
the
chairs
and
what
happens
during
last
call.
Obviously
that
is
the
end
of
my
presentation
on
this
draft.
I
see
Hana
Stroh
finna
get
the
microphone.
Thank.
D
You
Mike
a
question
or
it's
sort
of
like
your
your
feedback.
So
when
you
imagine
you
have
a
CWD
and
in
previously
in
the
JD
ability
we
provided,
for
example,
for
scopes
and
also
for
audiences
sort
of
like,
as
you
said,
with
scopes,
it
was
just
a
string,
presumably
something
that
is
even
meaningful
for
human
to
understand
and
for
for
the
audiences.
D
Ideally,
you
want
to
have
a
URI
just
pointing
to
the
server
so
that
the
matching
is
a
little
easier
to
do,
but
it
could
also
be
a
string
if
it's
particularly
if
it's
a
mighty
imagine
it
affects
multiple
different
parties.
So
in
a
in
a
gwd,
you
really
want
to
have
spent
as
little
space
as
possible,
but
still
we
today
have
a
sort
of
string
encoding.
D
C
C
Audience
might
be
a
URI,
but
it
is
very
intentionally
a
string
and
the
language
in
jot,
which
I
am
some
in
the
room,
wrote
mirrors
the
sam'l
language,
which
talks
about
a
value
that
the
recipient
identifies
itself
with.
That
doesn't
mean
it's
a
URL
of
the
thing.
It
could
be
a
logical
value
like
an
organization
name,
it
really
is
context
dependent
what
a
valid
audience
is,
and
so,
if
you
are
in
a
particular
profile,
I'm
sure
the
profiles
will
say,
this
is
the
format
of
an
audience.
C
But
at
this
sort
of
token
level
we
wanted
to
leave
appropriate
audience
values
up
to
the
profiles
of
me,
addresses
scope,
comment
and
then
take
the
next
speaker.
Scopes
are
not
something
defined
in
jots
and
one
of
the
simplifying
assumptions
going
into
this
work
that
I
think
has
held
up
well
over
time
is
we
were
going
to
exactly
parallel
the
claims
that
are
in
a
jot,
the
naseeb
or
web
token
established
the
parallel
registries.
C
So,
for
instance,
the
next
draft.
The
proof
of
possession
draft
will
use
that
registry
and,
in
fact
the
ace
o
auth
draft
will
use
that
registry,
for
instance,
to
define
a
scope
claim
in
the
context
of
seaboard
web
tokens
and
so
the
once
we
get
this
done.
The
mechanism
through
I
Anna
will
be
in
place
for
scopes
and
any
other
application
specific
claims
to
be
created
and
registered.
Now
what
scope
value
should
be
gosh?
What
are
they
in
Oh
us
right?
C
D
What
I
was
also
trying
to
get
to
is
I
was
wondering
whether
it
would
be
useful
to
define
maybe
an
additional
data
type
for
those
two
things
where
today
we
have
strings-
and
maybe
this
would
be
just
would
also
allow
maybe
integers
of
even
binary
values,
because
those
are
tend
to
be
more
efficiently
encoded,
I'm,
with
the
downside
of
basically
making
it
more
difficult
to
reuse,
existing
back-end
infrastructure,
because
they
are
a
user
interface,
obviously
wouldn't
allow
you
to
enter.
Let's
say
a
hex
value
to
just
represent
the
binary
value.
E
Yeah
cuz
moment
indeed,
so
you
said,
the
audience
is
a
string
that
somebody
identifies
with,
and
IOT
devices
often
identify
with
a
hash
of
the
public
key
with
what
with
a
hash
of
their
public
key,
and
it
would
be
nice
to
be
able
to
convey
this
hash
in
in
binary.
So
I
am
not
sure
what
the
right
answer
here
is,
so
one
answer
might
be.
We
we
opened
up
the
audience
claimed.
E
C
And
this
is
just
me
as
an
individual
talking
off
my
head
off
the
top
of
my
head,
but
the
Seaboard
data
format
is
types
up
descriptive
as
you
well
know,
and
so
if
the
working
group
thinks
it
is
the
right
thing
to
do,
we
could
allow
either
strings
or
binary
and
it
would
be
detectable
by
implementations
depending
upon
the
profile
it
could
make
some
implementations
bigger.
It
could
make
some
of
the
data
types,
smaller
and
I.
Think
that's
an
appropriate
thing
to
discuss.
During
the
present
working
group.
C
Last
call,
I
will
say
you
know,
there's
been
other
places
where
we
took
jose
and
jot
data
structures
and
did
change
the
type
of
them
jim
changed.
The
key
ID
and
jim
in
the
working
group
changed
the
key
ID
from
being
a
string
to
binary
in
COEs
a
that
was
probably
a
good
call,
and
so
you
know
I'm
not
religious,
about
everything
that
was
a
string
and
Jason
land
has
to
be
a
string
in
C
Borland.
There's
use
cases
that
it
may
make
sense
for
stuff
to
be
binary.
Yeah.
C
I'll
first
give
the
the
party-line
answer,
which
I
happen
to
believe
is
the
right
answer,
which
is
the
defined
claims,
are
those
in
the
iron
and
a
registry
for
CWT
claims
and
there's
the
registry
to
add
stuff.
This
Draft
adds
some
initial
claims.
The
top
draft
adds
some
more.
The
a
so
auth
draft
adds
some
more
and
to
the
extent
that
you
want-
and
this
was
one
of
my
comments
in
my
individual
review
of
the
a
so
auth
draft-
that,
to
the
extent
that
you
want
to
use
the
same
numeric
space
are
the
same.
C
Numeric
values
for
parameter
numbers
and
claim
numbers
I
would
suggest
actually
registering
those
as
claims
using
an
appropriate
part
of
the
number
space
and,
as
I
said
in
my
review
stuff,
it's
application
specific
should
not
be
using
the
one
byte
values
they
should
be
higher
up
in
the
space,
but
now
I'm
down
in
the
weeds.
Is
that
how
far
do
you
want
to
give
me
more
feedback
or
give
us
well.
E
You
Liberty
custard
yeah.
We
just
add
to
this
binary
thing.
Indeed,
C
was
safe,
descriptive.
It
may
still
be
hard
to
find
out
what
kind
of
binary
string
you
actually
looking
at
I
think
we
have
a
somewhat
reasonable
idea.
What
a
text
string
means
as
an
audience
I'm,
not
sure
we
have
that
for
a
binary
string,
so
we
could
define
that
or
we
could
say
well,
there
are
going
to
be
different,
minor
strings
and
we
use
different
claims
to
identify
that.
So
that's
the
question
and.
C
C
C
Instead
of
the
lazy
Jason
that
I'd
copied
over
from
RFC
7,800
and
samuel
added
a
table.
Helping
people
understand
the
overview
better
and
Jim
made
a
bunch
of
detailed
comments,
a
lot
of
them
on
exposition,
some
of
them
on
semantics,
which
the
author's
got
some
have
done
before
the
publication
cutoff
and
we
plan
to
work
on
those
this
week.
C
C
It's
entirely
possible
fact:
I
would
bet
that
there
are
still
places
where
there's
Jason
remnant
language
left
over
or
things
written
as
if
we
were
talking
about
Jason
that
we
should
instead
be
talking
about
Siebler,
and
so
my
request
would
be
even
hopefully
that
we
get
a
few
specific
names
in
the
minutes
of
people
who
are
willing
to
read
this
actually
very
short
draft.
Yes,.
A
C
C
C
F
F
You
perfect,
so
this
is
about
the
draft
ITF
ace
of
Alf
and
next
slide.
Please
version
0-8,
so
major
changes
from
zero,
seven,
two
zero.
Eight.
We
moved
the
discovery
of
the
authorization
server
from
the
details
profile
to
this
draft,
since
we
discussed
in
the
last
meeting
that
it
fell
generic
enough
to
be
in
the
framework
instead
of
in
a
hidden
in
the
profile.
F
F
Then
there
is
a
change
that
will
probably
be
discussed.
We
made
seaboard
mandatory
data
formats,
the
reasoning
behind
that
was.
If
you
have
the
bandwidth
to
use
JSON,
then
you
can
probably
use
a
wolf
and
dot
and
you
don't
need
ace.
So
that
is
like
open
for
discussion,
but
I
just
want
to
make
that
changes
to
make
the
to
to
spice
up
the
discussion.
F
We
made
the
claim
and
parameter
abbreviations
mandatory
with
the
same
reasoning
since
you
really
don't
want
to
have
code
that
needs
to
parse.
Both
it
makes
the
code
more
complex
and
it
makes
the
messages
larger.
So
if
you
have
the
bandwidth
to
do
that,
then
you
probably
can
use
wolf
right
away
and
also
we
made
it
mandatory
for
the
profiles
to
specify
not
only
the
security
between
the
client
and
the
resource
server,
but
also
between
the
client
and
the
authorization
server
and
in
case
they
support
introspection
between
the
resource
server
and
the
authorization
server.
F
D
Yeah,
if
specifically
on
this
on
this
mandatory
SIBO
format,
but
also
on
which
was
early
in
there,
also,
the
mandatory
co-op
format
I
think
it
specifically
with
the
last
line
you
mentioned.
That
profiles
now
also
need
to
indicate
the
client
authorization,
server,
interaction
and
I'm
curious
on
whether
be
we
should
probably
relax
us
a
little
bit
and
here's
my
thinking.
In
some
sense,
we
have
a
couple
of
probe
that
talk
about
protocol
mechanisms
that
go
beyond
the
use
of
coop.
D
According
to
this
framework,
I
have
to
use
C
bar
between
the
client
and
authorization
server,
which
also
doesn't
seem
to
be
right.
I
saw
I
think
we
should
be
a
little
bit
more
relaxed
about
our
what's
mandatory
and
what's
not
in
a
in
a
framework
and
leave
some
of
this
also
to
to
the
subsequent
profiles.
Okay,.
F
D
F
I
did
a
very
specific
line
of
text.
Saying
coop
is
just
used
as
an
example
throughout
the
document,
and
you
can
use
other
protocols
as
specified
by
profiles,
but
there
might
have
been
a
remanent
somewhere
that
that
sounds
like
what
was
mandatory.
Please
point
that
out
or
or
fix
it
yourself,
Yuriko
offer
go
ahead.
Yeah.
D
D
The
other
thing
is
that
I
wanted
to
bring
up,
which
is
not
on
a
slide.
Is
this
I'm
still
a
client
document,
I
I've
seen
my
crib,
you,
the
client
token
still
feels
a
little
odd
to
me.
It's
just
so
different
from
from
ours,
and
so
I
still
have
a
sort
of
a
fuzzy
feeling
about
it
because
it
has
just
received.
So
it's
it's
just
not
as
well
understood
as
many
of
the
other
parts.
So
there
seems
to
be
some
imbalance,
and
specifically
one
of
the
nice
things
about
the
other
sort
of
classical
most
models.
D
Is
that
if
you,
if
you
do
an
authentication
specifically,
if
you
involve
the
the
user,
you
can
use
any
authentication
mechanism
that
you
like.
But
then,
if
you
switch
to
this
client
token,
since
you
basically
have
to
talk
from
the
client
to
the
authorization
server,
why
are
there
are
s
in
in
a
one-shot
message?
You
obviously
can't
use
sort
of
any
authentication
mechanism,
so
essentially
we
are
down
to.
Presumably
some
public
key
was
symmetric,
key
mechanism
between
those.
D
So
so
it's
it
is
not
just
from
a
messaging
point
of
view
different,
but
also
from
an
architectural
point
of
view.
So
it's
it's
just
something
to
I'm,
not
entirely
sure
and
I
wonder
whether
we
have
enough
experience
to
put
it
into
the
framework
or
it
should
better
go
into
a
separate
document
and
and
get
some
more
security
analysis
first
can.
F
I
Here
we
are
so
I
had
a
couple
of
comments
on
on
one
of
the
comments
here,
let's
order,
so
if
we
take
the
last
thing
first,
on
the
client
token,
that
is
a
new
feature
in
a
switch
not
represented
in
in
OS
2.0,
and
it
basically
represents
the
difference
in
the
architecture.
So
in
ace
there
is
a
possibility
to
do
mutual
authorization,
so
it's
both
authorization
from
the
point
of
view
or
what
the
client
is
allowed
to
access
and
also
what
the
client
is
is
supposed
to
do.
I
Basically,
what
actions
the
client
intake-
and
there
are
use
cases
which
we've
seen
in,
for
example,
in
the
enrollment
setting
where
the
client,
both
the
client,
needs
to
be
authorized
to
enroll
at
the
client
in
salsa
to
know
it's
adjoining
device,
am
I
authorized
to
join
this
network.
So
in
that
setting
the
client
and
token
makes
sense,
then
it
actually
fits
with
the
architecture,
but
it
is
a
different
thing.
I
feel
still
think
it
should
remain
in
the
framework,
because
the
framework
is
sort
of
describing
the
entire
picture
which
is
painting.
I
That
was
one
of
the
comments.
Another
comment
was
regarding
to
see
where
mandatory
and
I
wonder:
is
there
a
difference
there
between
sort
of
where
you
mandate
C
or
we
are
now
looking
at
both
coming?
There
are
three
nodes
here:
is
the
client
a
resource
server
in
the
authorization
server
and
the
lake,
which
is
most
important
from
constrained
point
of
view,
is
between
the
client
and
the
resource
server.
So
that's
where
we
may
need
to
make
sure
that
the
objects
are
are
really
small
and
it's
low
complexity
in
the
processing.
I
D
Issue
so
that
that
makes
sense
to
me
because
also
if
we,
if
you
use
and
I
comes
back
to
my
earlier
comment
to
the
HTTP
comment,
if
you
use
o
as
regular
OS
with
HTTP,
then
you're
not
using
C
border,
obviously
so
so
in
that
sense,
it's
not
just
about
the
coop,
but
it's
also
about
about
this.
This
aspect
there's
another
just
as
you
said
like
see,
Bob
falls
into
this
the
question
of
how
do
you
encode
the
parameters
in
a
request,
but
also
the
the
SIBO
web
token
India?
D
It
I'm
not
sure
we
need
to
mandate
the
Siebel
web
token
itself
either,
because
it
is
some
cases
where,
obviously
the
client
doesn't
know
about
the
token
format.
The
resource
server
may
not
care
about
the
token
format
either,
because
it
may
do
an
introspection
and
may
actually
do
not
get
a
self-contained
token.
It
means
that
use
a
handle,
so
I
think
we
need
to
be
a
little
bit
more
careful
in
in
sort
of
mandating
things
in
a
framework
and
the
implication
it
may
cause
to
to
the
overall
architecture.
J
F
If
I
make
comment
myself,
one
drawback
with
making
sabor
optional
and
allowing
other
formats
is
that
it
also
increases
the
code.
Complexity
like
you,
have
to
prepare
a
code
to
to
receive
both
sibour
and
Jason
and
whatever
other
formats
we
later
come
up
with,
and
that
increases
the
possibility
of
ya
doing
something
wrong.
So
am
I
in
my
motivation
for
introducing
that
was
to
keep
the
code
simpler.
You
just
have
to
be
prepared
to
parse
Tibor,
but
I'm.
Not
that's,
not
the
hill
I'm
going
to
die
fighting
on.
C
So
this
is
Mike
Johnny's
from
Microsoft
I
agree.
We
want
the
code
to
be
simpler,
but
I
think
it's
very
unlikely
that
any
particular
implementation
would
support
multiple
formats,
at
least
in
an
IOT
context.
This,
after
all,
is
a
framework
document.
Not
a
protocol
document
and
particular
profile
documents
will
profile
the
framework
and
say
which
data
formats
to
use
which
protocols
to
use
what
the
format
of
an
audience
is,
etc,
etc,
etc.
C
Turning
it
into
an
actual
protocol
specification
right
and
I,
don't
think
it's
the
place
of
the
framework
document
to
bake
in
those
choices
or
the
profiles.
So
one
of
the
things
I
did
say
in
my
pretty
extensive
review
was
yes
define
new
features.
If
you
think
some
profiles
will
need
them
that
make
it
clear
that
whether
they're
required
as
a
profile
decision,
not
something
imposed
by
the
work
and
that's
a
comment
that
sort
of
flows
throughout
most
of
the
document
I.
A
E
D
All
right
actors-
but
this
is
honest-
one
line
comment
only
one
sentence,
I
think
I-
think
it's
not
as
traumatic
as
as
portrayed,
because
the
complexity
is
different
on
different
nodes.
I
think
it's
totally
acceptable
for
authorization
server
if
it
supports
a
diverse
set
of
use,
cases
to
support
a
chase,
on-base
encoding
and
the
Seaboard
based
encoding.
The
client,
from
a
token
point
of
view,
doesn't
need
to
understand
either
in
then
under
on
the
resource
server
side.
It
really
depends
what
I
use
token
introspection
or
not.
D
F
All
right
next
slide,
yes,
so
I
think
we
already
had
the
discussion
about
the
first
bullet
point
kind
token:
should
it
be
in
this
draft
or
should
we
split
it
out?
Basically,
my
arguments
for
were
it
covers
the
use
case
for
a
client
with
intermittent
connectivity,
and
we
define
that
use
case.
So
if
we
take
it
out
of
the
draft,
we
will
have
a
use
case
that
is
not
covered.
The
drawback
of
having
it
in
the
draft
is
the
session
is
a
most
pointed
out
in
the
discussion.
F
There
was
one
question
by
Mike
in
his
very
extensive
review
at
the
end,
and
that
was
the
relationship
to
token
binding
work
in
off
and
since
that
work
started
after
our
draft
I'm
not
really
familiar
with
it.
The
question
is,
cannot
be
specified
in
a
profile
and
would
someone
be
willing
to
write
that
drafts
I?
Leave
that
open
for
discussion
on
the
lists,
as
well
as
unless
someone
jumps
to
the
mic
and
volunteers.
F
F
Can
do
that,
but
not
now
I'm
going
back
to
sleep
after
this
presentation,
it's
2
a.m.
no
3
a.m.
for
me
and
the
third
bullet
point:
what
parameters
to
return
in
a
normal
threads
request.
That
was
a
comment
from
Jim
child
in
his
extensive
review,
so
Jim
suggested
that
the
resource
server
should
return
the
audience
and
scope
it
expects
for
a
unauthorized
request
and
obviously
it
should
be
in
in
a
format
that
is
not
readable
for
a
unauthorized
client,
but
only
for
the
authorization.
F
So
I
don't
know
if
we
want
to
discuss
this
now
we're
running
low
on
time,
I
guess,
since
we
had
an
extensive
discussion
before
we
might
be
running
low
on
time,
so
probably
a
good
idea
to
take
the
discussion
on
the
list,
but
that
is
like
the
big
issues.
I
saw
to
discuss
next
slide,
please
so
next
steps,
except
for,
of
course,
the
three
discussion
points
I
mentioned
is:
we
need
to
resolve
some
editorial
issues.
F
There
were
a
number
of
Ayana
related
comments
that
might
point
it
out
to
us
that
we
didn't
manage
to
fix
before
the
cutoff
and
that
we
will
do,
and
thanks
for
that
review,
I
asked
I
asked
specifically
asked
for
a
review
of
the
Ayane
sections
and
Mike
did
a
great
job
and
pointing
out
all
the
flaws
we
had
managed
to
build
in
there.
Otherwise
we
have
code
that
is
ready,
for
it
drops
at
least
for
the
current
working
group
drafts
version.
L
K
That's
one
and
I
think
this
relates
to
a
comment
that
Hannah's
had
last
meeting
on
the
multicast
document.
He
was
talking
about
interoperability
and
how
to
choose
your
profile
and
I.
Think
that's
a
comment
for
the
ACE
framework
rather
than
specific
profile,
and
the
other
thing
is
well.
I
would
have
a
use
of
it
in
in
the
pub/sub
profile
that
eyes
I'm
not
going
to
talk
about
it
this
this
meeting,
but
that
uses
two
profiles
for
about
publisher.
So
if
that
could
be
done
in
one
exchange,
that
would
be
good.
So.
F
F
I
didn't
see
this
I
think
there
is
some
text
saying
that
we
expect
client
and
the
resource
servers
to
be
registered
at
the
authorization
server,
and
there
is
an
appendix
specifying
what
what
knowledge
we
assume
the
authorization
server
has
of
both
the
client
and
the
resource
server.
Okay,
thanks,
but
I
might
need
to
go
through
the
text
and
make
you
this
clearer
in
case
it
isn't
so
I'll.
Take
that
as
a
future
work.
M
K
Hello,
so
this
is
a
status
update
for
do
score
profile
for
ace
and
some
next
steps,
so
the
US
co-op
or
now
it's
called
a
score
profile-
was
presented
at
ITF
97
and
we
are
version
0
6,
which
is
update
according
to
the
latest
or
score
updates,
which
are
minor.
We
have
moved
the
use
of
a
dog
to
an
appendix.
K
So
now
it's
not
in
the
main
body
of
the
document,
and
we
have
just
added
appendix
that
is
the
same
in
the
ACE
framework
saying
which,
which
parameters
the
profile
specifies,
and
there
are
two
implementations
in
progress,
open
issues
and
next
steps,
so
Thank
You
Ben.
Now
we
have
confirmed
that
it's
adopted
so
we're
going
to
submit
this
in
the
in
the
word
is
document
and
one
question
I
had
was.
K
A
I
Okay,
you're
a
cylinder:
can
you
hear
me
so
I'm
going
to
talk
about
the
DTLS
profile,
which
is
also
an
adopted
profile,
and
these
slides
were
prepared
by
all
of
Bergman?
None
he's,
unfortunately,
not
here
so
I
will
walk
through
the
slides,
just
a
reminder
or
a
for
those
who
are
new.
What
is
a
profile,
so
the
profile
is
essentially
something
which
transports
specifies,
how
you
transport
authorization,
information
to
a
resource,
server
and
keys
as
well,
and
these
keys
are
used
to
authenticate
and
the
authorizations
use.
I
I
So
there
were
issues
discussed
during
the
face-to-face
meeting,
some
issues
raised
by
hon
us
in
the
review
and
some
small
editorial
changes
and
we're
also
going
to
discuss.
It
is
meeting
some.
Some
open
issues
which
we
have
proposed
solutions
for
which
are
already
implemented
in
the
github
implementation
status,
is
that
there
is
two
implementations
which
are
already
as
far
as
I
know
to
this
to
this
version
of
the
document.
It's
the
six
implementation
and
Jim
also
has
one
implementation,
and
there
is
yet
another
implementation
plan
by
University
of
Bremen.
I
I
Using
this
key
identity
in
DTLS
and
the
issue
here
was:
how
does
the
client
know
which
method
it
should
use
when
it
communicates
with
the
resource
server
to
deduce
the
authorized
post
to
the
authorization
information?
That's
I
can
a
here
or
should
it
use
the
PSK
identity?
So
how
does
the
client
know
what
is
supported
in
the
resource
server
and
the
answer
to
a
is
very
simple
because
a
is
mandatory,
so
that's
something
that
the
client
always
could
use,
and
so
the
question
remains.
I
How
does
the
client
know
whether
the
PSK
identity
version
of
transporting
authorization
information
is
supported?
The
alternatives
are
essentially
that
either
some
information
is
provided
from
the
authorization
server
to
the
client,
which
is
telling
the
client
that
yes
is
resource
server
has
is
supporting
this
feature
or
the
client
you
just
try.
I
E
I
Ok,
so
that's
good
good
comment,
the
in
it,
since
the
only
mandatory
method
to
transport
authorization.
Information
is
using
a
in
general
that
would
always
be
possible
for
for
in
general,
but
you
may
have
a
profile
policy
on
on
a
particular
deployment
which
says
that
you
must
first
use
the
SK
identity
because
that's
part
of
the
authentication
procedure.
I
Okay,
so
that's
another!
It's
actually
not
this
issue,
it's
actually
another
issue
which
but
adds
a
constraint
to
how
to
resolve
this
issue,
so
that
also
so.
The
proposal
for
a
solution
of
this
particular
issue
number
10,
is
to
allow
the
trial
and
error,
and
that
strategy
also
works
for
the
security
policy
issue.
That
cares
to
mention
here,
because
you
could
always
try
to
make
a
post
to
the
authorization
info
and
get
back
and
not
authorised.
D
I
You
don't
so
you
can
still
implement,
only
I
mean
either.
This
is
a
deployments
specific
thing,
so
so
either
this
deployment
supports
unauthorized
access
using
post
authorization
info.
In
that
case,
you
only
need
to
implement
that
part,
or
this
is
another
deployment
which
says
that
you
must
authenticate
before
you
do
post
to
authorization
info,
and
in
that
case
you
could
implement
only
as
in
that
case
you
can
implement
both
the.
D
E
I
B
I
D
D
About
now,
but
the
interesting
thing
is
in,
if
you
then
use
the
short,
the
shortcut
of
the
shortcut
essentially
to
post
a
new
token,
the
pop
token
into
the
authorization
info
you
are
in
essence,
not
really,
you
are
skipping
the
re-authentication
but
which
you
still
put
put
the
roof.
Possession
of
the
key.
Actually
you
want
is
that
it's
not
a
problem.
E
I
I
I
Okay,
we
should
continue
this
discussion,
but
I
think
as
far
as
I
understand
now,
the
proposed
solution
addresses
also
Karstens
issue
here,
a
Carson's
point:
okay.
Next,
one
question
on
the
mailing
list
was
from
honest
I
think
on
whether
the
pre
shared
key
and
the
raw
public
key
are
two
different
profiles,
so
the
ACE
framework
supports
both
PSK
and
RPK,
and
if
we
specify
a
profile
with
coop
DTLS,
how
do
we
know
whether
that's
a
PSK
or
an
RPK
based
authentication
and
the
proposal?
Is
that
we
don't?
Oh
sorry
there?
This
is
an
open
question.
I
E
E
I
E
D
On
the
profiles,
I've
been
wondering
about
one
aspect,
namely
in
some
sense.
Like
the
PSK
versus
Rob
oblique,
he
seems
to
be
two
different
things,
but
in
terms
of
like
TLS,
it's
basically,
you
negotiate
these
aspects,
of
course,
that
the
server
could
dictate.
So,
if
you
have,
of
course,
you
could
have
potentially
the
mismatch,
so
the
authorization
server
would
provide
some
guidance
on
what
does
or
hints
what
does
the
other
party
the
resource
or
actually
implement.
D
But
on
the
other
hand,
it's
probably
less
sort
of
severe
as
it
is
because
of
the
negotiation
mechanism,
as
it
is
in,
let's
say,
a
difference
between
the
dis
DTLS
authorized
versus
that's
a
nqd,
because
then
you
would
obviously
have
a
deeper
problem
because
you
wouldn't
even
get
started
or
the
Oscorp
one.
So
that
would
be
different,
so
I'm
curious
on
whether
there's
actually
the
profiles.
D
What
is
a
possibility
to
actually
describe
not
just
in
I,
see
this
as
a
a
Lockhart
versus
sort
of
the
cipher
suite
approach
in
some
sense.
So
here
you
have
the
DTLS
or
or
TLS,
and
then
there's
the
transport
and
then
there's
also
a
credential
question.
Why
is
it
better
to
manage
this
together
and
thereby
you
have
indicate,
as
Francesca
previously
said,
you
indicate
the
list
of
different
cipher
suites
or
profiles,
but
then
you
have
to
use
one
of
those.
D
So
did
you
run
into
that
when
you,
when
you
worked
on
on
the
implementation,
did.
I
K
I
G
From
know,
I
have
just
from
implementing
this
I
mean
basically
whether
you're
doing
PS,
k
or
RP
k
is
pretty
easy
to
tell,
because
the
AF
identifies
to
the
client.
This
is
the
key
you
should
use
and
distinguish
between.
Those
two
is
pretty
easy,
yeah
and
in
theory
right
now,
the
a
s
is
supposed
to
be
configured
with
the
capabilities
in
terms
of
whether
the
client
in
the
serve
and
and
the
resource
server
can
do
which
of
these
they
can
do,
and
in
the
case
they
can
do
Rob
public
keys.
G
D
Why
that's
what
I
was
getting
to?
Maybe
I
didn't
express
myself
super
clear,
but
that's
why?
Maybe,
even
though
I
erase
this
issue
that
whether
this
is
one
or
multiple
profiles,
but
maybe
the
answer
here
is
this-
is
actually
the
profile
co-op
DTLS
it,
because
whether
it's
an
OP,
PK
or
dpsk
is
actually
information.
You
get
any
way
from
adapt
from
other
sites.
That
was
what
I
was
trying
to
articulate.
So
maybe
the
answer
to
my
original
question
is:
it
is
actually
one
profile,
but
it's
not
the
one
that
is
listed
up.
D
N
I
Very
good
now
we
some
things
here.
This
is
the
third
issue
chairs,
and
this
is
the
final
issue
and
then
there
is
some
some
wrap
up
just
so
issue.
14
is
dealing
with
the
related
issue,
as
was
discussed,
number
10,
but
PK
identity,
and
the
question
here
is
that,
since
there
are
multiple
options
to
use
the
PSK
identity,
what
is
the?
What
is
the
complexity
in
in
the
implementation
as
a
result
of
this?
I
So,
for
example,
PSK
identity
is
now
with
the
DTLS
profile,
it's
overloaded,
so
you
could
also
I
contain
an
access
token,
as
well
as
an
ordinary
key
ID
identifier.
So
how
will
the
resource
server?
How
will
this
be
implemented,
or
do
you
need
to
indicate
whether
a
PSK
identity
contains
an
access
token
or
a
key
identifier,
and
the
proposal
which
is
so
committed
on
the
github
you
could
look
at
it
is
that
we
actually
allow
the
the
resource
server
to
to
again
try
try
the
different
options.
I
So
when
you
receive
these
K
identity,
you
first
verify
whether
this
actually
identifies
the
key
which
you
could
use
for
DTLS
or
and
if
not,
then
you
try
to
verify
the
by
string
as
if
it
were
an
access
token.
So
that's
the
proposal
to
handle
complexity,
also,
in
that
case,
at
both
both
cases
are
supported
and
you
don't
need
to.
You
only
need
to
have
a
sequence
of
processing
steps
identifying,
which
are
the
cases
in
a
particular
request.
I
I
One
issue
which
we
may
discuss
here
is
the
mandatory
curve
for
implementation,
and
the
proposal
from
from
the
authors
is
to
use
the
Edwards
Kirby
ad
two
five,
five
one
nine.
So
this
is
marking
a
progression
from
from
ECDSA
to
EDD
si,
which
we
think
is
the
right
step.
Take
here,
another
thing,
which
is
also
already
implemented
as
a
proposal,
is
to
use
binary
data
in
PSK
identity.
So
previously
the
text
required
base
64
encoding,
but
that's
not
necessary.
I
I
Had
a
final
comment,
then
from
my
side
and
that's
an
announcement
from
my
employer
with
regards
to
the
note
well
that
erickson
may
have
ITR
on
this
draft
and
there
is
an
IPO
declaration
in
progress
to
be
announced
this
week.
So
you
could,
as
usually
you
could
follow
the
links
from
the
drive
to
find
out.
Okay,
okay,
Thank
You,
Marco
Europe.
O
Hi
market
localized,
six,
quick
updates
on
this
other
profile
of
Ace.
Of
course,
the
goal
is
20
below
IPSec
miscommunication
between
client
and
server
resource
server
in
ace,
taking
advantage
again
of
the
independence
of
IPSec
for
the
sake
of
key
management
and
establishment.
So
you
can
go
in
principle
for
reestablished
pairs
of
security
associations
or
activity,
as
particular
example
of
establishment
in
symmetric
or
asymmetric
mode,
and
the
penances
are
of
course
limited
only
to
the
ACE
framework
and
in
particular,
IP.
Second,
a
key
with
you.
O
This
is
just
an
example.
With
reference
to
activity,
you
and
I
said
the
profile
supports
both
direct
provisioning
of
security
associations
prepared
and
issued
by
D
of
transition
server,
or
you
can
go
for
an
actual
his
table.
Shman
protocol,
especially
activity,
of
course,
both
in
symmetric
or
asymmetric
key
based
mode.
O
O
But
you
can
in
principle,
also
further
means
and
any
other
relation
for
alternative
establishment.
Most
of
the
nike
BQ
is
purely
informative
now
and
totally
move
to
the
appendices.
The
biggest
news
is
actually
that,
as
I
mentioned
in
prague,
we
were
working
on
an
implementation
that
is
not
completed
for
kontiki
and
available
on
a
non-public
heat
up,
support
in
both
the
direct
provisioning
of
security
associations
and
activity,
both
symmetric
and
asymmetric
key
mode,
and
that
was
tested
on
solar
cell
Firefly
modes
and
we're
currently
running
advanced
performance
evaluation
to
support
it's
a
scientific
publication.
E
P
Dan
Harkins,
it
looks
like,
and
here
you
can
send
an
access
token
request
with
with
a
asymmetric
key
in
it,
but
from
the
looks
of
it
you
don't
have
a
way
of
doing
proof
of
possession
of
the
private
key.
When
you,
when
you
make
that
request
and
I
think
what
happens
then
is
you
can
open
up
the
subsequent
Ike
exchange
to
an
unknown
key
share
attack,
so
I
think
you
should
either
provide
some
way
of
doing
proof
of
possession
sort
of
like
what
s
does
where
it
signs
the
TLS
unique
from
the
the
TLS
session.
O
Hi
Marco
joke
again,
so
few
updates
also
this
other
work
on
joining
Oscar
multicast
groups
in
ace.
So
here
the
goal
is
to
support
joining
of
multicast
groups
where
group
members
communicate
through
group
co-op
using
Oscar
to
protect
communications
in
the
group,
and
the
point
is
joining
the
group
by
using
the
ace
framework
and
specifically
its
profiles
and
the
proto
such
is
obliviously
the
specific
profile
you
decided
to
use
and
still
it's
flexible,
to
arrange
groups.
O
Few
things
are
not
covered
in
this
document
as
otoscope.
At
the
moment,
one
is
further
authorization,
specific
resource
access
of
resources
hosted
at
group
members,
that's
just
up
again
to
the
ACE
framework
and
I'm,
possibly
prophecy
decide
to
use,
and
second,
the
actual,
secure
communication
in
the
group
based
on
multicast
so
scored.
That
is
instead
described
in
detail
in
the
specific
document
in
the
core
important
group.
O
O
Compared
to
the
previous
version,
we
had
a
number
of
little
changes,
and
especially,
we
clarified
something
about
the
provisioning
and
handling
of
public
keys
of
group
members.
Now
we
especially
recommend
that
the
group
manager
is
configured
to
be
repository
of
public
keys
of
group
members
that
they
have
to
provide
them,
then
upon
their
own,
join
and
then
also
to
address
some
comments.
We
got
in
Prague
to
avoid
possible
scalability
issues.
O
O
Second
one
as
I
mention
in
the
previous
slide,
it
is
right
now
out
of
scope
to
entrust
the
authorization
server
for
anything
but
authorizing
an
access
to
the
group
manager
for
starting
the
joint
process,
but
in
principle
the
same
authorization
server
can,
of
course
be
used
also
to
ensure
authorization
to
access
resources
at
group
members.
So
should
we
consider
this
point
in
scope
for
this
draft
and
in
case,
how
should
the
two
authorizations
be
combined
in
a
single
step.
O
Third
and
important
one:
there
were
spotted
similarities
between
the
use
of
this
framework
in
this
document
and
in
the
pub/sub
profile
other
than
previous
thoughts
on
further
generalizing,
the
pub/sub
profile
for
group
communication
and
then
in
the
wrong
way
on
the
ACE
framework.
Both
drafts
address
key
provisioning,
so
possibly
parts
of
them
can
be
merged,
and
especially,
there's
need
to
avoid
the
definition
of
multiple
sets
of
messages
covering
this
very
single
so
about
this.
What
do
you
think?
The
best
way
to
proceed
is
also
with
respect
to
documents.
I
Your
answer
boundary,
so
your
open
points
here,
two
and
three
I
suppose
they
are
potentially
related
so
because,
in
the
pub
side
profile
you
actually
get
directly
from
the
authorization
server
an
access
token.
So
so
that's
essentially
kind
of
similar
question
and
the
first
open
point
was
more.
Is
that
more
about
the
format
or
aware
thing?
Is
it
about
the
format
or
about
where
things
are
specified?
We
are
specified
mostly
okay,
so
it's
whether
things
goes
into
the
multi,
Coast
or
craft
or
whether
it
goes
into
the
joining
dress.
It's.
O
Other
than
that,
as
next
steps,
of
course,
we
are
going
to
keep
this
document
along
with
the
history
framework
and
its
profiles
and
other
data
that
can
be
added
in
the
main,
multicast
Oscar
document
in
core
and,
of
course,
for
the
common.
Some
reason
these
are
welcome
and
we
are
going
to
address
the
open
points
have
just
mentioned,
then.
On
top
of
this,
this
draft
got
like
high
priority
label
after
the
latest
ace
interim
meeting.
So
we
wonder
what
is
needed
to
proceed
towards
adoption
later
on.
A
N
A
Q
Q
Okay,
don't
work
so
it
proposes
to
have
used
coop
and
detail
s
to
support
est.
The
application
areas
are
secure,
bootstrapping
devices
and
also
distribution
of
identity
and
keying
material
I
must
make
an
understatement
now.
This
is
understated
in
the
current
version
of
the
DAF
that
they
are
these
two
aspects
of
the
HT
over
:.
Q
The
two
application
areas
where
the
original
motivation
comes
from
is
to
used.
It
is
to
use
this
in
risky
with
the
60s,
so
we
know
the
pledge
and
the
joint
proxy
and
the
stevis
has
been
dumped
in
animal
and
we
want
to
do
the
same
thing
for
small
devices.
On
the
other
hand,
there
isn't
clear
wish
also
to
use
eesti
instant
alone
and
to
have
the
oil
point
listed
with
the
registration
authority
talking
to
each
other
and
ask
that
is
a
different
aspect.
I.
Q
Would
just
to
say
some
of
the
issues
which
I
know
about
so
first
of
all
is
that
the
motivation
of
the
draft,
which
is
just
current
them
about
Brisky,
should
be
extended
and
that
you
also
should
talk
about
that.
We
have
two
standalone
version
that
should
be
emphasized
more
there.
Isn't
this
isn't
proposal
by
Hollis
to
have
a
second
draft
and
that
we
could
split
I
think
it
might
be
impossible
solution?
We
should
discuss
that
in
more
detail.
There
is
a
section
about
proxying
in
the
HT
draft.
Q
On
the
one
hand,
this
rather
terse
it
tells
you
about
proxy
in
between
the
coop
speed,
the
cooperate
and
the
HTTP
world.
You
might
also
say:
maybe
we
don't
want
it
in
this
context,
so
that
is
one
of
the
things
which
is
not
quite
clear
here
in
this
document.
There
are,
of
course,
many
extensions
to
the
est
which
have
to
do
with
the
British
key,
but
just
about
getting
vouchers
and
to
support
the
tappan
sportif
outer
the
surface
side.
Key
generation
has
not
been
put
forward.
Q
On
the
other
hand,
there
are
quite
a
lot
of
decisions
taken
here
in
the
east
ii
of
corpus
of
a
co-op
draft
to
remove
functions
which
are
supported
by
ESD,
because
we
were
served
and
thinking
solely
about
the
Brisky
applications.
So
probably,
if
you
want
to
have
a
standalone
version,
all
functions
of
the
ESD
should
be
supported.
Q
J
Hi
this
is
Hank,
and
this
is
a
very
high-level
remark,
but
I
really
like,
like
a
lying
out,
blueprints
and
architectures
that
show
how
to
compose
the
existing
building
blocks.
So
I
think
this
stuff
has
merit
and
is
useful,
so
it
is,
it
is,
although
it
is
really
explaining
existing
things,
it
is
very
important
to
show
how
to
compose
them.
Okay,.
A
This
is
Eliot
I,
also
like
the
drab.
Having
had
some
discussions
with
you
in
Hannah's
I,
also
like
the
idea
of
making
sure
that
things
are
and
I
agree
with
Hanks
point
that
things
should
be
properly
composed.
I
look
forward
to
working
with,
with
both
of
you
and
I'm
happy
to
review
and
work
with
you
on
the
draft.
Okay.
Q
So
other
things
to
do
a
part
of
having
this
discussion
is
humless
about
how
the
the
draft
should
the
structure
of
the
draft
should
evolve,
etc.
There
we
had
to
fill
in
operational
parameter
values
because
for
the
moment,
the
only
side
them,
but
they
don't
give
any
idea
about
what
tell
you
should
be
used.
The
motivation
section
should
be
changed
because
we
want
to
have
support
it.
Two
different
application
area,
the
server-side
key
generation-
should
be
added
and
probably
more
things
if
you
want
to
have
this
instant
alone,
I'm
very
happy.
D
Wondering
about
the
server-side
key
generation,
because
I
thought
that
one
of
the
prime
values
of
e
TST
was
actually
that
it
was
on
a
client
site
and
having
this
server
generating
keys.
Obviously,
like
creates
a
bigger
security
vulnerability,
because
now
you
have
even
for
like
a
public
key
cryptosystem
in
our
half.
Essentially,
the
two
part
is
knowing
the
private
key
right.
That
I
could
imagine
like,
from
an
operational
point
of
view,
liability
point
of
view.
That
would
be
not
the
ideal.
Okay,
yeah.
Q
I
understand
that
point,
but
people
who
are
thinking
that
this
villain
approach,
especially
about
the
survive,
mature,
higher
possibility
of
generating
keys
vision,
okay
I
forgot
to
avert
larger
set
of
keys,
which
I
have
reliable.
So
that
was
so
we
using
an
already
reliable
channel.
We
want
to
renew
the
keys
and
we
can
use
the
self
regeneration
from
the
surface
ID,
as
the
client
may
not
be.
R
A
So
we've
had
I
guess
for
quite
a
long
time
some
expensive
discussions
about
the
group
communication,
security
topic
and
you
know,
there's
been
debate
about
using
a
symmetric,
key
based
scheme
or
a
symmetric
key
based
scheme,
and
so
we
really
do
want
to
try
and
get.
You
know
the
sense
of
the
working
group
as
to
where,
where
we
are
and
what
we
want
to
do
so,
I
guess
one
of
the
no
key
questions
is
just
from
a
security
and
sort
of
security
model
and
threat
model
perspective.
What
are
the
actual
requirements
and.
A
If
I
putting
up
the
slide,
so
I
can
actually
see
them
too
so,
like
we
know
that
with
these
things,
we've
got
low
costs
and
the
latency
constraints,
and
we
want
to
translate
that
into
you
know
actual
security
requirements.
So
we
can
analyze
different
proposals
and
see
what's
gonna
work,
you
want
to
jump
in
yeah
as
you're
going
through.
This
may
I
suggest
a
couple
of
things.
First
of
all,
there's
never
going
to
be
a
single
set
of
requirements
here
that
the
different
devices
different
deployment
models.
A
You
know
what
what
you
need
in
a
nuclear
power
plant.
It
may
well
be
different
than
say
what
you
need
for
your
enterprise
lighting
solution
right
and
I
think
we're
trying
to
focus
on
the
lighting
solution
Oh.
What
I
was
gonna
suggest
is
we'd
like
to
think
horizontally
in
this
organization.
You
know
to
cover.
Is
you
know
if
we
can
cover
all
the
cases,
and
we
have
two
choices
right?
We
could
be
very
narrow
and
which,
as
you're
suggesting
then
or
we
can
allow
for
the
capabilities
to
support
both
and
I.
A
Think
that
in
itself
is
a
question
right.
So,
for
instance,
let's
just
be
absolutely
crystal
clear.
You
know
as
an
example,
our
signatures
required
on
every
single
message
that
emits
from
a
device
right,
I,
think
we
have
that
on
the
next
slide
right,
so
the
point
being
right
that
the
answer
is
always
going
to
be
sometimes
right.
A
D
One
is
so
we
know
about
one
specific
use
case
and
there
we
had
people
participating
in
a
list
explaining
what
their
requirements
are
and
I
was
the
indoor
commercial
lighting
example.
There
was
some
other
nebulous
cases,
but
we
don't
have
the
community
here.
We
don't
understand
exactly
what
they
want.
I,
don't
understand
what
people
want
in
nuclear
power
plants
with
this
I,
don't
think
we
should
design
for
solutions
for
them.
D
Even
though
we
like
to
work
in
a
very
generic
case,
but
at
least
we
have
one
use
case,
which
is
like
volume
buys
industry
by
its
large
enough
to
justify
some
work.
So
I
think
we
should
focus
something
that
we,
where
we
have
the
community
at
hand
and
they
asking
us
for
a
solution,
we're
working
as
with
some
of
the
companies
in
indoor
lighting
sector,
and
they
have
expressed
those
requirements,
and
so
maybe
we
we
want
to
provide
them
a
story
that
might.
A
Might
take
on
it
great,
and
so
if
we
can
think
about
that
particularly
use
case-
and
you
know
the
requirements
of
that
use
case
and
your
hopefully,
everyone
has
read
the
slide
by
now.
Does
this
seem
like
a
reasonable
translation
of
their
requirements
into
security
requirements
and
that's
a
question
for
you
know
entire
room,
not
just
Aramis.
I
You're
answered
on
the
side:
I
haven't
really
read
through
I'll,
read
through
it
in
a
minute,
but
the
people
that
I've
been
talking
to
in
this
industry
in
terms
of
building
automation
lighting,
they
express
the
need
for
a
solution
which
can
support
both
the
case
of
low
latency
and
and
less
strict
source
authentication
like
group
type
identification
as
well
as
source
authentication.
So
both
these
requirements
exist
both
would
require
multicast
both.
A
Q
L
S
A
requirement,
but
not
a
security
requirement.
This
is
Dave
Robin.
Yes,
the
I
was
going
to
point
out
that
in
building
automation,
systems
versus
security
systems,
for
example,
latency
affects
the
security
requirements,
meaning
for
lighting
humans
want
the
lights
to
all
come
on
at
once.
Therefore,
we
need
to
make
some
compromises
in
security.
However,
the
command
from
a
fire
system
to
open
all
access
doors
does
not.
It
needs
to
be
highly
secured,
but
does
not
necessarily
have
to
be
low-latency.
S
So
you
see,
the
trade-off
is
versus
latency
versus
security
and
I
just
want
to
throw
that
out
there,
and
so
the
nuclear
power
plant
is
not
going
to
shut
down
all
the
pumps
immediately,
because
a
human
isn't
going
to
say:
hey
these
pumps
didn't
all
shut
down
at
once.
It's
going
to
do
very
secure,
unicast
communication
to
each
one
so
group
communications
that
can
be
what
repla
caste.
We
call
it.
You
know,
which
is
an
individual
thing.
S
I
have
this
list
of
group
members
I
need
to
send
them
to,
but
they're,
not
multicast
they're
one-to-one
they're
secured
in
one
on
one.
That's
a
list
of
people
to
receive
the
message
and
there's
no
latency
requirement
there
other
than
do
it
as
fast
as
you
can,
but
for
the
case
where
the
latency
is
absolutely
critical.
Like
lighting,
we
have
to
trade
that
off
with
a
little
less
security.
D
Yeah
and
I
think
specifically
the
case
where
we
had.
We
didn't
have
the
latency
issue
in
the
discussions.
The
unicast
communication
was
perfectly
fine.
I,
don't
think
we
had
a
problem
with
any
of
the
unicast
communication
or
any
of
the
the
public.
He
tripped
I
think
the
contentious
issue
was
about
symmetric
group
communication
security.
That
was
the
contentious
issue,
the
other
other
things
were
no-brainer.
T
Like
st.
John's,
one
of
the
things
that's
happened
in
this.
In
this
thing,
we've
gone
over
and
over
again
on
the
low
latency
thing
and
I
was
thinking
about
back
when
I
was
dealing
with.
T
Voice
over
IP
and
the
people
saying
ringing
must
start
immediately.
You
know
when
you
pick
up
when
you
when
you
press
the
button,
it
must
not
ringing
within
a
small
amount
of
time.
Well,
guess
what
the
systems
don't
work
that
way,
so
what
ended
up
happening
is
you're
in
starts
ringing
and
pretending
it's
actually
happening.
So
there
are
other
ways
of
solving
the
low
latency
problem
rather
than
this
multicast
group
thing,
especially
when
you're
talking
about
well,
how
many
lights
are
you
talking?
How
many
lights
are
you?
G
G
G
D
So
among
the
solutions
that
we
had
entertained
on
a
million
years,
I
think
this
one
is
new
just
to
change
the
user
sort
of
behavior,
but
the
other
solutions
that
we
have
heard
so
far
was
one
is
to
use
some
new
public
key
cryptosystems,
like
Derek
proposed
the
other
one
was
to
use
different
hardware
sort
of
different
processors.
Hardware,
acceleration
and
I-
think
the
multicast
Plus
group
symmetric
key
was
the
was
the
preference
in
terms
of
solution
from
the
from
the
lighting
community
and
we
didn't.
D
We
never
managed
to
make
a
proposal
on
restricting
the
use
of
the
protocol
in
such
a
way
that
Mike
would
be
satisfactory,
so
he
keeps
pushing
on
us
sort
of
restricting
it
and
profiling
it
or
whatever
it
in
a
way.
When
he
then
goes
off
and
says,
it's
actually
not
possible
to
do
that,
because
there's
always
the
nuclear
power
plant
that
can
use
it
and
they
will
get
it
wrong.
There
are
always
some
people
who
will
misuse
it
and
will
do
it.
T
Just
trying
to
figure
out
whether
or
not
to
respond
to
the
ad
hominem
but
I,
don't
think
I
will
the
keys.
Would
you
sit
down
for
a
second?
Let
me
finish.
The
key
thing
here
with
respect
to
this
protocol
is
that
if
you
break
into
any
device
you
get
privileged,
you
can
raise
your
privilege.
So
if
you
break
into
a
light,
not
a
light
switch
and
get
this
key,
you
can
raise
your
privilege.
T
That
is
a
that,
is
basically
just
an
insecure
protocol
and
again,
unless
we
limit
it
to
this
really
specific,
really
I,
don't
care
about
security.
What
we're
gonna
pretend
we
have
security
field.
Then
we
have
to
be
careful
about
this
working
out
into
the
wild,
we're
reusing
DNS
for
things
that
it
was
never
designed
to
do.
I
expect
something
like
that
to
happen
here,
but.
T
I'm
saying
that
I
think
I
can
come
up
with
solutions
that
do
things
don't
involve
privilege
raising
if
I
don't
if
I
don't
deal
with
the
multicast
single
key
thing
in
that
thing
so
and
that's
the
NASA
thing
I'm
talking
about,
but
again
the
limitations
are,
then
how
many
can
you
put
in
for
your
things?
So
there's
a
whole
bunch
of
trade-offs
here,
I'm,
not
comfortable
with
the
trade-offs
they've
made
for
this
as
a
general
protocol.
A
All
right
two
points:
the
first
is
that
I
should
just
point
out
that
this
work
has
actually
been
performed
right.
The
in
other
standards
bodies
at
this
point,
both
I-
think
it's
KNX
and
ZigBee.
Both
have
now
group
based
mechanisms
that
do
multicast,
but
do
not
in
fact
deal
with
a
key
management
issue
which,
if
you
ask
me,
is
the
hard
part.
A
So
the
point
is
that
you
know
the
question
is:
can
we
improve
on
the
work
that
they
do?
Can
we
actually
raise
the
bar
on
security
and
help
and
actually
provide
value
into
the
industry
and
I
think
the
answer
to
that
is
clearly
yes,
because
we've
had
of
these
several
proposals
that
do
just
that.
The
second
point
I
wanted
to
make
is
that
I
think
we
have
a
bit
of
an
application
transport
mix-up
here,
which
is
I.
A
You
know
in
terms
of
what
they
have
with
appropriate
warnings,
and
you
know
caveats
and
yada
yada
yada,
but
you
know
part
of
that
might
be
in
the
in
the
data.
You
know
you
know,
object
signing
when
it's
necessary
and
or
you
know,
as
in
the
case
of
the
fire
control
system.
Part
of
it
may
be
not
having
that.
But
if
we
can
separate,
maybe
get
you
know
the
transport
from
the
application
we
might
be
able
to
move
forward
on
this
a
little
easier.
D
Under
the
sun
is
we
have
tried
to
phrase
the
language
in
the
document
to
fulfill
what
Mike
was
asking
for,
but
unfortunately
never
got
any
sort
of
like
input
on
what
he
would
have
really
liked
to
see
that
it
actually
fulfills
his
need
like
in
terms
of
text.
It
was
just
we
tried,
no
tried,
no
tried.
No.
That
was
not
very
helpful
for
us
in
order
to
progress
on
Elliot's
point
and
a
little
bit
related
to
my
point.
This
is
not
about
no
security
group.
Communication
is
not
no
security.
D
Why
areas
is
related
to
ace
and
actually
in
here's,
because
the
age
framework,
with
the
authorization,
server,
client
dot
for
the
authorization
server
getting
keys
and
then
using
those
keys
is
actually
the
key
distribution
mechanism.
So
it's
not.
We
are
not
talking
about
manufacturer,
provided
group
keys
in
all
the
devices
which
are
then
used
to
issue
commands.
That's
not
what
we
are
talking
about
here.
We
are
talking
about
the
client
authenticating
to
the
authorization
server
which
happens
to
be
then
acting
as
a
key
distribution
server
in
sort
of
the
cameras
type
of
style.
D
D
U
So
they
favor
I
have
a
couple
different
comments
on
the
slides
here.
So
let
me
talk
about
first,
the
one
that
people
haven't
talked
about
before,
but
it
is
related
and
then
I'll
touch
on
I.
Think
what
I
hear
from
other
people
say
the
one
that
I
haven't
seen
touched
on.
It
has
to
do
with
the
latency
constraints,
and
this
goes
back
to
the
comment
about
application,
layer,
transport,
layer
or
network
layer
or
whatever,
which
is,
if
you
care
about
latency.
U
You
also
typically
care
about
reliability,
not
always,
but
in
many
cases
like
I
want
to
turn
on
the
lights
or
I
want
to
turn
the
lights
red
or
whatever.
It
is
that's
something
that
wants
reliability
right,
I
need
to
know
that
they
actually
got
on
as
opposed
to
I
have
to
retransmit
or
whatever.
So
that's
actually,
the
impact
on
the
transport
layer,
not
the
security
protocol
right,
the
transport
layer
threat,
and
so
the
question
here
is
about
what's
the
security
requirements,
okay,
because
it
actually
touches
on
multiple
layers
here,
and
so
this
gets
to
I.
U
Think
Mike's
point
about
multicast
is
needed
for
efficiency.
That's
a
point!
That's
about
the
network
layer
and
technically
about
the
transport
layer.
If
you
care
about
the
reliability
mechanism
as
well,
not
the
security
layer
and
so
I
would
like
the
requirements,
because
this
is
concrete
security
requirements,
not
concrete
Network
layer
or
transport
layer
requirements
is
the
context
of
the
slide.
U
That
I
think
the
notion
of
whether
you're,
using
multicast
or
not,
is
not
a
security
requirement,
and
so
in
that
sense,
I
think
I
completely
agree
with
Mike
at
least
I
think
that
was
one
of
his
points
anyway.
He's
hang
raving,
maybe
not
completely
all
right,
fine.
He
said
it
looks
plain
it
and
then
finally,
the
topic
on
the
low
security
environment
and
the
fourth
bullet,
which
is
the
intent
operate
in
relatively
homogeneous
systems.
I
think
the
fourth
bullet
is
probably
better
worded
than
the
third
bullet.
U
I
think
the
third
bullet
is
not
worded
as
a
requirement,
it's
worded
as
a
justification
for
a
lack
of
requirements
right.
The
fourth
bullet
is
actually
closer,
because
the
constraint
is
really
that
you're
saying
when
you're
talking
about
things
like
shared
keys
and
elevation
of
privilege,
like
Mike,
was
talking
about
that.
One
role
can
somehow
get
permission
into
another
role,
because
there's
only
one
shared
key
or
whatever
is
actually.
If
the
requirement
is
to
be
efficient,
when
you
only
have
one
role
and
everybody
is
considered
equal,
that
is
one
type
of
security
requirement.
U
Okay,
as
opposed
to
a
requirement
to
support
multiple
roles
like
asymmetric
roles
like
light
switch
versus
light
and
trying
to
separate
minimal
number
I
think
there's
a
big
difference
between
one
and
more
than
one
and
for
the
security
requirements.
It
would
be
useful
to
either
say
we
need
a
solution
sufficient
for
exactly
one
role
where
everybody's
appear
and
everybody's
treated.
Equally,
that
everybody
all
authorized
entities
are
treated
equally,
all
right,
you're,
either
authorized
you're
not
authorized
or
there's
a
requirement
is
important.
U
Multiple
types
of
roles,
that's
actually
an
interesting
security
requirement,
because
I
hear
the
solution
being
one
and
I
hear
other
people
arguing
for
the
requirement
is
actually,
if
you
care
about
security,
you
want
to
allow
for
multiple
roles.
I
think
that
part
was
actually
closer
to
Mike's
main
point.
This
is
what
is
the
actual
security
requirement
when
a
target
may
be
there's
two
different
ones
here,
but
two
different
solutions
and
one
of
them
are
gonna,
do
first,
one
of
them
is
later
whatever
and
I.
G
On
a
second
I
have
a
question
for
you.
So
if
we're
looking
at
the
lighting
scenario,
the
fact
that
we're
with
you
would
not
necessarily
say
that
we
that,
from
the
solution
point
of
view,
we
would
need
to
distinguish
between
activators
and
luminaries.
The
fact
that
a
luminary
can
activate
the
rest
of
luminaries
is
not
a
problem.
If
we
are,
if
we
are
basically
saying
everything's,
the
same
sorry
I'm,
not
sure
I
understood
your
question
from.
U
U
U
Lighting,
yes,
whether
you
call
in
to
our
commercial
depends
on
what
you're
using
my
my
point
is
that
there
is
a
need
to
do
asymmetric
where
the
restrict
the
set
of
people
that
can
issue
commands.
That
set
is
different
from
the
set
of
people
that
can
receive,
commands
or
I
should
say,
entities,
not
people
right.
T
No
okay,
so
yeah
I've
never
claimed
this
doesn't
have
any
security,
but
the
security
is
all
in
the
confidentiality
piece
and
turns
out
that
that's
actually
a
useful
model
for
multicast
group
communications,
because
what
you're
doing
is
protecting
the
transmissions
or
the
data
and
guess
what,
if
you're
one
of
the
receivers
who's
supposed
to
be
getting
it?
If
you're
breaking
to
the
receiver,
you're,
not
doing
a
privilege,
privilege
elevation
because
you're
getting
the
data
that
you
would
have
gotten
anyways.
T
So
that's
why
some
of
this
is
okay,
like
I
said,
the
second
bullet
is
like
well,
okay,
that's
really
what
a
group
symmetric-key
multicast
thing
works
for,
or
it
works
for
everything
in
Commons,
a
single
domain.
Anything
everybody
can
control
everybody
else.
It
doesn't
work
for
this
asymmetric
stuff
in
any
way.
T
That
is
you
get
to
the
point
where
this
is
such
a
limited
space
that,
like
I,
said
I'm,
not
sure
why
the
lighting
people
just
didn't,
write
their
own
document
and
doing
informational
so
anyway,
you've
gotten
all
of
what
I'm
saying
many
times,
I'm
sorry
to
keep
saying
it.
I
hate
getting
misrepresented,
because
what
I
have
said
in
the
documents
is
basically
you
need
to
fix
this
as
a
general
thing,
I
keep
telling
them
you're,
offering
me
a
tomato,
and
what
you
really
need
is
a
banana
or
something
along
those
lines.
D
I'm,
honest
I
just
wanted
to
point
out
that
lighting
is
not
equal
to
lighting,
so
you
have
commercial
lighting,
indoor
lighting.
This
is
the
stuff
on
the
ceiling
over
there
hundred
luminaires.
You
turn
them
on.
You
have
things
like
a
certain
expectation.
You
you
push
the
button
till
the
light
goes
on
a
time
limit
of
about
200
milliseconds.
You
also
don't
want
to
ask
cascading
effect,
so
you
turn
on.
If
you
do
unicast,
you
see
one
light
going
on.
It
looks
like
an
avalanche
effect.
You
don't,
apparently
the
lighting
community
doesn't
want
that.
D
If
you
look
at
the
home
environment,
you
have
one
two
lights
going
off,
it
does
matter.
There's
no
cascading
effect.
That
requirements
are
different.
If
you
have
street
lighting
again
different
requirements,
so
just
because
lighting
appears
enter
in
a
name,
it
doesn't
actually
mean
it's
the
same
requirements.
D
S
This
day,
Robin
of
Dave
Taylor
just
said
something
that
is
not
on
this
slide.
That
I
think
is
very
important
and
it
has
to
do
with
the
reliability
of
the
delivery,
and
that
is
a
fundamental
thing.
Are
we
creating
a
reliable
group
delivery
mechanism
or
not
in
this
group
exactly,
but
that
that
has
a
lot
to
do
with
the
design
of
the
messages
you're
sending
if
it's
not
reliable
than
my
entire
application?
Space
has
to
be
designed
to
be
identity',
I
have
to
say
ramp
to
20
percent,
not
ramp
by
20
percent.
S
D
A
Okay,
I'm
gonna,
move
to
the
next
slide,
and
we've
had
some
good
discussion
about
these
security
requirements
as
listed
and
some
modifications
to
them.
So
we
have
some
more
questions
to
think
about,
and
so
the
first
one
is
here:
are
we
comfortable
creating
a
document
that
targets
this
level
of
security
and
maybe
for
this
level
of
security
we
can
think
about
there's
only
one
type
of
thing.
You
know
everybody
has
the
same
permissions
just
to
have
something
concrete
to
talk
about
you
know
and
ask:
are
we
comfortable
doing
some
work
at
that
level
of
security.
I
I
A
G
Yeah
I
mean
I
I,
believe
that
we
basically
already
are
have
agreed
that
we're
going
to
try
to
work
on
something
that
does
do
the
source
authentication.
All
that,
because
I
mean
that's
the
group
communication
stuff.
What
we're
looking
at
really
in
this
case
is,
do
we
also
want
to
work
on
something
at
that
of
the
very
low
end
where
we
don't
have
the
same
set
of
asymmetric
capabilities.
A
So
I'd
suggest
that
the
answer
that
is
yes
and
for
one
it's
for
several
different
reasons,
but
one
that
comes
to
mind
immediately,
though,
is
that
I
think
there
are
people
who
are
looking
for
a
solution
within
the
context
of
their
existing
hardware
framework.
So
they
can
at
least
be
get
to
some
level
of
secure,
and
you
know
they've
told
me,
for
instance,
that
128-bit
ECDSA
still
provide
still
requires
a
sufficient
latency
that
that
that
that
they
end
up
with
what
they
call
the
popcorn
effect
and
they
they
missed
their
200
millisecond
window.
A
And
so
my
thinking,
though,
is
that
over
time
that
Layton
sees
will
reduce
based
on
what's
available.
But
at
the
moment
things
are
almost
going,
the
opposite
direction,
and
so
having
the
symmetric
versus
ation
and
having
those
both
of
those
choices
available
allows
for
progression
into
the
asymmetric
space
when
there,
when
it's,
when
it's
possible
for
them
to
do
so,
it
may
not
be
possible
for
a
z80
to
meet
that
requirement
and
there
are
z,
80s
out
there
doing
this
stuff
excellent.
T
One
one
of
the
questions
I
actually
asked
once
upon
a
time
and
I've
been
able
to
actually
get
a
straight
answer
from
anybody
is
whether
any
of
the
lighting
systems
are
our
safety
and
health
concerns.
For
example,
I
understand
there
are
some
types
of
lights
that
are
manufactured
for
hospitals
that
have
and
I
that
have
a
UV
mode
to
them.
Okay,
can
you
imagine
this
system
being
compromised
and
turning
those
things
on,
because
somebody
was
able
to
get
the
key
out
of
one
of
the
lights
I
get
nervous
about
things
like
that.
Yeah.
A
A
Yeah
I
was
just
gonna
say
so
what
if
I'm
gonna
repeat
what
Dave
just
said,
which
is
that
that
doesn't
invalidate
the
use
case
that
we're
discussing?
But
you
know
the
my
opinion,
I,
don't
Hanna
I
think
this
tip
is
gonna
differ
hurt,
but
my
in
my
opinion
is-
or
my
perception
at
least,
is
that
yes,
there,
there
are
different
environments
that
that
work,
that
where
lighting
is
more
or
less
critical
in
terms
of
it
in
terms
of
its
security
and
that
it's
important
that
the
people
who
are
in
those
environments
take
them.
A
A
U
Take
care
of
just
explaining
my
off
mic
comment:
I,
said
Arbor
health
issues
with
lighting,
yes,
but
it
doesn't
Intel
eyes
the
use
case
right.
The
the
yes
is.
If
you
can
rapidly
turn
things
on
and
off,
you
can
cause
epileptic
seizures.
That's
the
example
right,
there's
other
examples,
but
that's
the
most
obvious
one
that
there
are
potential
health
impacts,
but
it
does
not
invalidate
the
use
case.
U
I
mean
you
still
want
to
do
it
even
though,
because
there's
just
little
likelihood
that
somebody
might
have
epilepsy
and
be
triggered
by
something
I
think
it's
still
valuable
to
have
a
low
security
mode,
meaning
a
one
role
mode.
I
think
it
is
valuable
to
have
a
multiple
role
mode
and
it's
valuable
for
the
working
group
to
define
authorization
models
and
protocols
to
do
both,
and
so
are
we
comfortable?
T
Yeah,
the
the
confident
I
mean
the
single
role
sort
of
a
confidential,
a
role
or
a
common
or
a
common
domain
role
which
isn't,
unfortunately,
which
is
somewhat
not
what
what
it's
been
going
on
with
the
lighting
stuff,
the
low
security
again
the
problem
so
much.
The
problem
is
that
in
some
ways
the
low
security
role
that
we've
been
talking
about
is
equivalent
to
no
security.
T
So
I
guess
I
get
worried
because
I
don't
understand
what
I
don't
understand.
If
this
protocol
will
be
used
brought
in
a
broader
set
than
the
things
that
we've
got,
my
guess
is
it
will
be
because
it
will
be
something
that's
less
by
the
ietf
and
people
will
go.
Oh
cool,
it's
secure.
We've
had
that
happen
before
this
one,
because
we're
now
talking
about
cyber
physical
stuff
concerns
me
more
than
I
would
if
this
were
just
a
simple
data
protocol.
D
T
Three
foot
fence
provides
security
against
the
grasshopper,
doesn't
provide
a
lot
of
security
against
a
guy
walking
over
it.
So
again,
the
question
is:
do
we
have
a
high
it?
Does
this
provide
a
high
enough
fence
to
be
worth
protecting
against
a
a
guy
with
$1000
with
a
thousand
dollar
laptop
start
that
take
that
as
my
basis
for
what
I
think
the
minimal
barrier
to
entry
is
here.
V
Quinn
day,
so
when
we
think
about
security
to
me,
there
are
three
cases:
either
we
say:
oh
I,
don't
need
security
for
this,
then
you
know
you
do
what
you
want
to
do.
Or
you
say
security
is
important
here
and
you
have
to
provide
a
secure.
V
The
real,
secure
solution
like,
for
example,
you
know
be
56
or
add
you
know,
to
fight
one
eye,
for
example,
or
you
can
say,
okay
I
want
to
to
to
apply
for
this
special
case,
and
then
you
have
to
do
the
analysis
for
the
cost
and
the
benefit,
and
in
order
to
do
that.
Well,
is
this
family
hard,
because
the
the
costs
and
everything
else
keep
changing,
and
you
have
to
look
at
the
at
the
attacker
perspective.
V
You
know
the
cost
and
the
benefits,
and-
and
this
will
offer
you
to
be
sure-
that
your
net
assets
a
correct
because
keep
changing
and
your
attackers
could
be
anyone
and-
and
so
it
would
be
very
dangerous
for
us
to
go
into
that
direction
and
to
recommend
and
say
this
is
okay
for
able
to
use
because
I
don't
see
the
good
way
how
to
do
that
matrix
for
the
risks
and
benefits
it
costs
and
and
and
the
and
and
the
advantage
we
get
from
from.
You
know:
weak,
secure
security
solutions.
V
So
is
this,
it
would
be
really
bad
and
also
our
solution
could
be
adopted
in
many
places
and
when
it
will
see
it's
fast
enough
and
they
just
go,
do
it-
they
don't
think
too
much
about
it.
But
in
order
for
for
IDF's
camellia
to
give
a
good
security
solution,
we
either
give
a
very
good
one
niches
secure.
You
can
use
it
or
you
can
provide
the
analysis
for
people
to
say:
hey,
you
do
this
matrix
calculation
and
it
looks
like
looks
good
to
you.
V
Then
you
can
do
it,
but
I
I
would
not
feel
comfortable
with
the
ladder
option,
because
I
don't
know
how
to
do
that
calculation
incorrectly
because
they
keep
changing
and
it's
so
many
place.
So
here
you
cannot.
You
cannot
do
that
it
just
no
no
chance
to
do
that
right
and
in
this
day
we
are
really
important
organization
to
provide
security
solution
and
recommendation,
and
that
would
be
very
dangerous
for
us
to
go.
You
know,
let's.
U
Thank
you.
Thank
you
for
putting
up
this
slide,
so
we
know
where
you're
going
next
and
I
like
this
slide,
because
it
says
it's
asking
about
a
solution
and
not
taking
into
account
the
details
of
any
particular
solution
at
that
context.
These
questions,
so
these
are
good
questions
and
I
wanted
to
potentially
have
suggest
a
adding
of
another
question
which
you
might
think
of
as
splitting
the
first
question
into
two,
because
I
want
to
distinguish
in
at
the
question
level,
between
low
security
systems
and
single
role
systems.
U
T
Gonna
make
a
suggestion
to
resolve
this,
something
that
I
think
might
actually
split
the
baby
in
half
a
few.
Well,
the
current
document
with
respect
to
multicast
group
group,
II,
multicast
security,
contains
a
symmetric
component
and
an
asymmetric
component
publish
that
document
with
both
of
those
mandatory
then
publish
a
second
document,
which
is
a
lighting
profile
which
releases
the
tree,
which
basically
relaxes
the
mandatory
for
that
particular
domain.
Specifically
for
the
lighting
case.
T
H
So
Kathleen
Moriarty
ad
I,
like
that
suggestion,
the
only
problem
I
have
with
it,
is
when
you
do
profile
documents,
and
it
may
be
of
an
answer
to
this.
If
we
are
stating,
must
and
must
so
mandatory
to
implement
on
both
of
those,
then
the
profile
has
to
have
that
must
as
well.
So
what
do
you
propose
for
the
flexibility
that
you're
suggesting.
T
H
H
See
we
would
even
come
down
on
other
stos,
for
this
and
I
have
direct
experience
with
that,
so
yeah
I
mean
I.
I
spent
10
weeks
of
my
life
going
to
a
particular
sto
to
make
sure
the
profile
rules
were
adhered
to.
So
that's
right.
That's
right!
There
were
some
nice
things
about
the
city.
I
won't
mention
it,
but
if
you
have
or
if
others
have
creative
ideas
along
that
line,
you
should
can
be
bendable
in
that
way.
But
musts
can't.
A
S
This
Dave
Robin
just
want
to
define
what
low
security
means,
because
I
can't,
if
I,
don't
know
what
that
term
means.
Are
you
talking
about
algorithms
and
bit
lengths
and
key
distribution
mechanisms,
or
are
you
talking
about
simply
symmetric
versus
asymmetric
ie?
What
happens
to
a
compromised
device?
S
That's
right!
That's
I'm,
agreeing
entirely
with
Dave
Taylor
privilege
escalation
compromise
device.
If
you
have
a
symmetric
system,
a
ador
controller
can
pretend
to
be
the
authentic.
The
controller,
controller
and
issue
commands
to
other
door
controllers.
However,
let
me
say
that
that's
that's!
Okay.
You
have
to
understand
that
a
single
device
can
have
multiple
security
domains
in
it
and
the
the
controller
controller
that
sends
out
things
like
day
mode
and
night
mode.
S
That's
a
multicast
X
that
can
be
a
symmetric
key
and
that
it
can
even
be
compromised
because,
as
we
go
back
to
our
original
slides,
it's
not
devastating.
If
you
compromise
that
it's
annoying
somebody
walks
up
and
goes-
oh,
my
god,
my
key
doesn't
work.
I
gotta
go
get
somebody
to
let
me
in
because
the
stupid
thing
thinks
it's
a
night
mode
so
that
that's
a
less
that's!
Okay!
If
somebody
compromised
that
it's
not
disastrous,
but
the
fire
control
system
that
says
open
the
door,
damn
it,
that
is
an
asymmetric,
not
symmetric
mode.
S
It's
another
role
within
that
device
and
it's
never
shared
it's
a
one-to-one
with
the
main
fire
controller.
So
it's
okay,
that
you
can
have
two
different
kinds
of
security
within
the
same
device,
but
they
might
be
using
the
same
exact.
You
know
D
TLS
or
a
key
length
or
whatever.
That's
not
we're
talking
about
so
I
need
to
know
what
low
security
means
in
order
to
know
how
to
vote
on
that.
So,
yes,
I
think
we
produce
low
security
in
that
you
consider
symmetric
to
be
lower
than
asymmetric.
A
W
Brian,
wise
Cisco,
so
the
the
one
comment
on
that
well,
oftentimes.
We
think
about
for
group
security
systems.
What
are
the
threats
to
those
and
we're
willing,
for
example,
maybe
to
say
a
local,
unquote
low
security
system?
Is
it's
a
group
level
security
with
symmetric
keys,
because
at
least
we
believe
that
it
takes
somebody
to
assuming
we
have
a
strong
authentication
system
to
the
key
server.
Then
at
least
it
takes
somebody
to
do
a
physical
attack
to
get
the
the
king
material
out.
Okay,
the
other.
My
real
question
is
on
the
third
bullet.
G
The
third
one
bullet
could
actually
be
either
symmetric
or
asymmetric.
As
far
as
I'm
concerned,
it
is
just
having
source
authentication
of
some
type.
The.
I
I
So
so
I
think
that's
a
possible.
How
is
this
real
but
I
think
it's
a
possible
solution
that
we
actually
did
something
similar
in
the
cosy
document.
So
in
the
cosy,
if
you
recall
the
cosy
document,
the
algorithm
is
mandatory,
but
Appendix
A
describes
an
exception
and
under
certain
conditions
you
don't
need
to
provide
the
algorithm
in
the
Koshi
object.
E
J
Hi
this
is
Hank.
This
is
from
I,
think
cross,
sto
point
of
view.
I
heard
the
word
compromised
thing.
A
lot
in
this
discussion
and
apparently
secure
means.
That's
not
compromised
and
I.
Think.
Therefore,
everything
here
is
low
security,
because
proving
that
something
is
compromised
is
kind
of
really
difficult
and
so
I
think
the
scope
of
the
question
depends
on
better
defining
what
you
think
is
secure,
you're
talking
about
keys
and
asymmetric
and
stuff,
but
but
a
thing
being
compromised
is
not
the
thing
we
are
talking
about
here.
J
I
think
we
can't,
because
we
cannot
show
that
it
is
compromised
or
not
compromised
and
and
I
think
that's
dangerous
assume,
because
we're
talking
about
light
bulbs
all
the
time
you
can
see
that
it's
going
off
on
because
you
can
see
it.
That
is
a
bad
example.
Most
things
are
not.
You
cannot
see
if
they're
compromised
and
proving
that
there
are
compromises
pretty
much
out
of
scope
of
this
stay
over
here,
I
think
mostly
yet.
N
Sam,
why
we're
echoing
something
I
think
I
just
heard
a
slightly
different
form,
which
is
we
really
need
to
pay
closer
attention
to
requirements?
We
have.
We
were
just
giving
an
example:
the
device
we
care
a
lot
about
of
a
fire
door
and
people
saying
well.
We
we
care
about
whether
it
gets
a
fake
command.
We
actually
care
less
about
getting
a
fake
command
to
open,
then
at
not
getting
a
command
so
being
the
difference
between
an
authentic
and
undelivered
command.
A
A
It's
loading
louder
and
perhaps
not
a
surly
number,
okay.
So
so
next
question:
should
we
so
now,
instead
of
low
security?
Let's
talk
about
the
single
role
systems,
where
all
all
participants
have
the
same
privilege
and
a
compromise
of
one
compromises,
the
entire
system.
So
we
think
that
that
sort
of
system
is
a
problem
that
we
should
address
in
the
ITF.
If
you
think
yes,
please
hum
now.
A
X
So
what
you're
describing
is
what
disarming
is
a
type
of
type
of
system
design
and
is
the
question
is
whether
this
kind
of
system
design
acceptable
to
us
is
something
we
want
to
describe
or
or
do
we
well
yeah.
A
Q
B
T
Sorry,
so
the
question
is
part:
two
is
in
an
interest
of
this
group
to
work
on
a
system
where
the
characteristics
of
the
system,
where
are
all
members
of
the
group,
share
equal
privilege.
So
the
compromise
of
one
group
of
one
member
does
not
result
in
any
additional
privilege
revelation
elevations
that
it
fairer.
H
H
T
She
wants
to
do
the
whole
thing
over
again.
Let
me
let
me
try
with
the
low
security
humps.
The
low
security
case
is
a
case
where
not
all
devices
shared
the
same
privileges
and
the
compromise
of
one
device
allows
for
privilege.
Elevation
allows
you
to
gain
privileges.
You
don't
have
to
you
shouldn't,
be
getting
sat.
A
A
A
A
Okay,
so
the
next
one
will
point
to
so:
if
we
have
okay,
can
we
can
we
move
on
to
the
next
time?
Please,
okay!
So
if
we
have
systems
where
all
the
voices
share,
the
same
level
of
privilege
and
the
compromise
of
a
single
device
does
not
grant
any
more
privileged
than
that
device
already
had.
Is
that
a
type
of
of
system
that
we
want
to
address
the
IETF
please
home
now
for
yes,.
A
A
A
G
A
A
A
We
also
want
to
work
on
the
core
framework
document
and
try
and
get
that
to
work
in
group.
Last
call,
of
course,
doesn't
mean
the
working
group
last
call
would
be
passed
by
then,
but
get
it
to
that
point
we
do
want
to,
you
know,
have
an
adoption
called
make
a
decision
about
group
communication
and
we
got
some
input
from
the
hums
and
then
the
est
work
in
a
similar
situation,
and
you
know
also
for
the
multicast.
We
want
to
try
and
get
a
sense
of
you
know.
D
I
A
A
So
I'll
tell
you
what
this
is:
Eliot
I'll
tell
you
what
I'm
gonna
take
from
that
series
of
Hondas,
which
is
you
know
we
didn't
make
really
much
of
a
decision
here,
but
rather
that
the
people
who
are
working
on
documents
need
to
listen
to
those
hums
and
and
try
and
navigate
a
way
to
find
consensus
to
move
the
documents
forward
in
terms
of
the
interpretation
and
that
interpretation,
but
I'll,
say
this
I
was
talking
to
Dan
in
the
back
there.
One
of
the
things
I
think
that
would
be
very
helpful
as
we
go
through.
A
All
of
this
is
that
in
each
of
the
documents
a
clear
threat
model
is
is
defined,
so
people
understand
what
they're
getting
what
they're
not
getting
in
each
in
each
case,
and
if
the
documents
are
attempting
to
be
comprehensive
right,
then
you
say
well
with
this
option.
You
get
this
with
it
with
with
this
option.
You
don't
get
this
and
that
addresses
these
threats
and
having
it
tied
to
that
I
think
will
help
us
in
London
move
forward.
I,
agree,
I,
think
that
would
be
helpful
and,
of
course,
people
can
probably
read
the
slides.
A
Do
we
have
interest
in
another
interim
for
any
of
these
topics
or
a
hackathon?
Actually,
we
would
like
to
have
a
hackathon
on
the
core
framework,
so
we
can
get
a
better
understanding
of
what
the
you
know,
what
the
needs
are
and
how
it's
gonna
work
and
if
we
need
any
more
changes,
because
we
would
really
like
implementation
experience
on
the
core
framework,
so
we
can
get
a
better
sense
of
how
close
to
done
it
is
and
I
think
we
are
over
time
at
this
point,
so
we
have
to
let
you
go
thanks.