[Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02

[Hannes Tschofenig]

Hi Jim,

I would like to comment on this issue.

-
> > 14.  I have real problems w/ the use of a KID for POP identification.  It
may
> identify the wrong key or, if used for granting access, may have problems
w/
> identity collisions.  These need to be spelt out someplace to help people
> tracking down questions of why can't I verify w/ this CWT, I know it's
right.
>
> The Key ID is a hint to help identify which PoP key to use.  Yes, if a Key
ID is
> sent that doesn't correspond to the right PoP key, failures may occur.  I
view
> that as usage bug - not a protocol problem.  If keys aren't consistently
known
> and identified by both parties, there are lots of things that can go
wrong, and
> this is only one such instance.  That said, I can try to say something
about the
> need for keys to be consistently and known by both parties, if you think
that
> would help.

> My problem is that if there are two different people with the same Key ID,
either intentionally or unintentionally, then using the key ID to identify
the key may allow the other person to masquerade as the first person.  I am
unworried about the instance of a failure to get a key based on a key id.
That is not the problem you are proposing to address.

-

I think we should document this issue. Here is some text proposal that could go 
into a
separate operational consideration section (or into the security consideration 
section instead).

"
- Operational Considerations

The use of CWTs with proof-of-possession keys requires additional information 
to be shared
between the involved parties in order to ensure correct processing. The 
recipient needs to be
able to use credentials to verify the authenticity, integrity and potentially 
the confidentiality of
the CWT and its content. This requires the recipient to know information about 
the issuer.
Like-wise there needs to be an upfront agreement between the issuer and the 
recipient about
the claims that need to be present and what degree of trust can be put into 
those.

When an issuer creates a CWT containing a key id claim, it needs to make sure 
that it does not
issue another CWT containing the same key id with a different content, or for a 
different subject,
within the lifetime of the CWTs, unless intentionally desired. Failure to do so 
may allow one party
to impersonate another party with the potential to gain additional privileges.
"


Ciao
Hannes

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02

[Jim Schaad]

That language works if you assume that there is only one CWT that an RS will
look to.  If there are multiple CWTs then one needs coordination language
between them.

> -Original Message-
> From: Hannes Tschofenig 
> Sent: Friday, June 22, 2018 6:36 AM
> To: Jim Schaad ; 'Mike Jones'
> ; draft-ietf-ace-cwt-proof-of-
> possess...@ietf.org
> Cc: ace@ietf.org
> Subject: Key IDs ... RE: [Ace] WGLC on draft-ietf-ace-cwt-proof-of-
> possession-02
> 
> Hi Jim,
> 
> I would like to comment on this issue.
> 
> -
> > > 14.  I have real problems w/ the use of a KID for POP
> > > identification.  It
> may
> > identify the wrong key or, if used for granting access, may have
> > problems
> w/
> > identity collisions.  These need to be spelt out someplace to help
> > people tracking down questions of why can't I verify w/ this CWT, I
> > know it's
> right.
> >
> > The Key ID is a hint to help identify which PoP key to use.  Yes, if a
> > Key
> ID is
> > sent that doesn't correspond to the right PoP key, failures may occur.
> > I
> view
> > that as usage bug - not a protocol problem.  If keys aren't
> > consistently
> known
> > and identified by both parties, there are lots of things that can go
> wrong, and
> > this is only one such instance.  That said, I can try to say something
> about the
> > need for keys to be consistently and known by both parties, if you
> > think
> that
> > would help.
> 
> > My problem is that if there are two different people with the same Key
> > ID,
> either intentionally or unintentionally, then using the key ID to identify
the
> key may allow the other person to masquerade as the first person.  I am
> unworried about the instance of a failure to get a key based on a key id.
> That is not the problem you are proposing to address.
> 
> -
> 
> I think we should document this issue. Here is some text proposal that
could
> go into a separate operational consideration section (or into the security
> consideration section instead).
> 
> "
> - Operational Considerations
> 
> The use of CWTs with proof-of-possession keys requires additional
> information to be shared between the involved parties in order to ensure
> correct processing. The recipient needs to be able to use credentials to
verify
> the authenticity, integrity and potentially the confidentiality of the CWT
and
> its content. This requires the recipient to know information about the
issuer.
> Like-wise there needs to be an upfront agreement between the issuer and
> the recipient about the claims that need to be present and what degree of
> trust can be put into those.
> 
> When an issuer creates a CWT containing a key id claim, it needs to make
> sure that it does not issue another CWT containing the same key id with a
> different content, or for a different subject, within the lifetime of the
CWTs,
> unless intentionally desired. Failure to do so may allow one party to
> impersonate another party with the potential to gain additional
privileges.
> "
> 
> 
> Ciao
> Hannes
> 
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
recipient,
> please notify the sender immediately and do not disclose the contents to
any
> other person, use it for any purpose, or store or copy the information in
any
> medium. Thank you.

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02

[Benjamin Kaduk]

On Fri, Jun 22, 2018 at 01:36:16PM +, Hannes Tschofenig wrote:
> Hi Jim,
> 
> 
> > My problem is that if there are two different people with the same Key ID,
> either intentionally or unintentionally, then using the key ID to identify
> the key may allow the other person to masquerade as the first person.  I am
> unworried about the instance of a failure to get a key based on a key id.
> That is not the problem you are proposing to address.
> 
> -
> 
> I think we should document this issue. Here is some text proposal that could 
> go into a
> separate operational consideration section (or into the security 
> consideration section instead).
> 
> "
> - Operational Considerations
> 
> The use of CWTs with proof-of-possession keys requires additional information 
> to be shared
> between the involved parties in order to ensure correct processing. The 
> recipient needs to be
> able to use credentials to verify the authenticity, integrity and potentially 
> the confidentiality of
> the CWT and its content. This requires the recipient to know information 
> about the issuer.
> Like-wise there needs to be an upfront agreement between the issuer and the 
> recipient about
> the claims that need to be present and what degree of trust can be put into 
> those.
> 
> When an issuer creates a CWT containing a key id claim, it needs to make sure 
> that it does not
> issue another CWT containing the same key id with a different content, or for 
> a different subject,
> within the lifetime of the CWTs, unless intentionally desired. Failure to do 
> so may allow one party
> to impersonate another party with the potential to gain additional privileges.
> "

When would this be "intentionally desired"?  It seems like there would be
better ways to share authorization between parties than to issue such
duplicate CWTs.

-Ben

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02

[Mike Jones]

I think you're looking for language something along these lines, right Jim?

"Likewise, if PoP keys are used for multiple different kinds of CWTs in an 
application and the PoP keys are identified by Key IDs, care must be taken to 
keep the keys for the different kinds of CWTs segregated so that an attacker 
cannot cause the wrong PoP key to be used by using a valid Key ID for the wrong 
kind of CWT."

-- Mike

-Original Message-
From: Jim Schaad  
Sent: Friday, June 22, 2018 7:59 AM
To: Hannes Tschofenig ; Mike Jones 
; draft-ietf-ace-cwt-proof-of-possess...@ietf.org
Cc: ace@ietf.org
Subject: RE: Key IDs ... RE: [Ace] WGLC on 
draft-ietf-ace-cwt-proof-of-possession-02

That language works if you assume that there is only one CWT that an RS will 
look to.  If there are multiple CWTs then one needs coordination language 
between them.

> -Original Message-
> From: Hannes Tschofenig 
> Sent: Friday, June 22, 2018 6:36 AM
> To: Jim Schaad ; 'Mike Jones'
> ; draft-ietf-ace-cwt-proof-of- 
> possess...@ietf.org
> Cc: ace@ietf.org
> Subject: Key IDs ... RE: [Ace] WGLC on draft-ietf-ace-cwt-proof-of-
> possession-02
> 
> Hi Jim,
> 
> I would like to comment on this issue.
> 
> -
> > > 14.  I have real problems w/ the use of a KID for POP 
> > > identification.  It
> may
> > identify the wrong key or, if used for granting access, may have 
> > problems
> w/
> > identity collisions.  These need to be spelt out someplace to help 
> > people tracking down questions of why can't I verify w/ this CWT, I 
> > know it's
> right.
> >
> > The Key ID is a hint to help identify which PoP key to use.  Yes, if 
> > a Key
> ID is
> > sent that doesn't correspond to the right PoP key, failures may occur.
> > I
> view
> > that as usage bug - not a protocol problem.  If keys aren't 
> > consistently
> known
> > and identified by both parties, there are lots of things that can go
> wrong, and
> > this is only one such instance.  That said, I can try to say 
> > something
> about the
> > need for keys to be consistently and known by both parties, if you 
> > think
> that
> > would help.
> 
> > My problem is that if there are two different people with the same 
> > Key ID,
> either intentionally or unintentionally, then using the key ID to 
> identify
the
> key may allow the other person to masquerade as the first person.  I 
> am unworried about the instance of a failure to get a key based on a key id.
> That is not the problem you are proposing to address.
> 
> -
> 
> I think we should document this issue. Here is some text proposal that
could
> go into a separate operational consideration section (or into the 
> security consideration section instead).
> 
> "
> - Operational Considerations
> 
> The use of CWTs with proof-of-possession keys requires additional 
> information to be shared between the involved parties in order to 
> ensure correct processing. The recipient needs to be able to use 
> credentials to
verify
> the authenticity, integrity and potentially the confidentiality of the 
> CWT
and
> its content. This requires the recipient to know information about the
issuer.
> Like-wise there needs to be an upfront agreement between the issuer 
> and the recipient about the claims that need to be present and what 
> degree of trust can be put into those.
> 
> When an issuer creates a CWT containing a key id claim, it needs to 
> make sure that it does not issue another CWT containing the same key 
> id with a different content, or for a different subject, within the 
> lifetime of the
CWTs,
> unless intentionally desired. Failure to do so may allow one party to 
> impersonate another party with the potential to gain additional
privileges.
> "
> 
> 
> Ciao
> Hannes
> 
> IMPORTANT NOTICE: The contents of this email and any attachments are 
> confidential and may also be privileged. If you are not the intended
recipient,
> please notify the sender immediately and do not disclose the contents 
> to
any
> other person, use it for any purpose, or store or copy the information 
> in
any
> medium. Thank you.

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02

[Mike Jones]

See my note just now proposing this text to Jim:

"Likewise, if PoP keys are used for multiple different kinds of CWTs in an 
application and the PoP keys are identified by Key IDs, care must be taken to 
keep the keys for the different kinds of CWTs segregated so that an attacker 
cannot cause the wrong PoP key to be used by using a valid Key ID for the wrong 
kind of CWT."

As long as the PoP keys for different contexts are kept segregated, Key ID 
collisions or reuse cause no problems.

-- Mike

-Original Message-
From: Benjamin Kaduk  
Sent: Friday, June 22, 2018 1:44 PM
To: Hannes Tschofenig 
Cc: Jim Schaad ; Mike Jones 
; draft-ietf-ace-cwt-proof-of-possess...@ietf.org; 
ace@ietf.org
Subject: Re: [Ace] Key IDs ... RE: WGLC on 
draft-ietf-ace-cwt-proof-of-possession-02

On Fri, Jun 22, 2018 at 01:36:16PM +, Hannes Tschofenig wrote:
> Hi Jim,
> 
> 
> > My problem is that if there are two different people with the same 
> > Key ID,
> either intentionally or unintentionally, then using the key ID to 
> identify the key may allow the other person to masquerade as the first 
> person.  I am unworried about the instance of a failure to get a key based on 
> a key id.
> That is not the problem you are proposing to address.
> 
> -
> 
> I think we should document this issue. Here is some text proposal that 
> could go into a separate operational consideration section (or into the 
> security consideration section instead).
> 
> "
> - Operational Considerations
> 
> The use of CWTs with proof-of-possession keys requires additional 
> information to be shared between the involved parties in order to 
> ensure correct processing. The recipient needs to be able to use 
> credentials to verify the authenticity, integrity and potentially the 
> confidentiality of the CWT and its content. This requires the recipient to 
> know information about the issuer.
> Like-wise there needs to be an upfront agreement between the issuer 
> and the recipient about the claims that need to be present and what degree of 
> trust can be put into those.
> 
> When an issuer creates a CWT containing a key id claim, it needs to 
> make sure that it does not issue another CWT containing the same key 
> id with a different content, or for a different subject, within the 
> lifetime of the CWTs, unless intentionally desired. Failure to do so may 
> allow one party to impersonate another party with the potential to gain 
> additional privileges.
> "

When would this be "intentionally desired"?  It seems like there would be 
better ways to share authorization between parties than to issue such duplicate 
CWTs.

-Ben

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02

[Jim Schaad]

> -Original Message-
> From: Benjamin Kaduk 
> Sent: Friday, June 22, 2018 10:44 PM
> To: Hannes Tschofenig 
> Cc: Jim Schaad ; 'Mike Jones'
> ; draft-ietf-ace-cwt-proof-of-
> possess...@ietf.org; ace@ietf.org
> Subject: Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-
> possession-02
> 
> On Fri, Jun 22, 2018 at 01:36:16PM +, Hannes Tschofenig wrote:
> > Hi Jim,
> >
> >
> > > My problem is that if there are two different people with the same
> > > Key ID,
> > either intentionally or unintentionally, then using the key ID to
> > identify the key may allow the other person to masquerade as the first
> > person.  I am unworried about the instance of a failure to get a key
based
> on a key id.
> > That is not the problem you are proposing to address.
> >
> > -
> >
> > I think we should document this issue. Here is some text proposal that
> > could go into a separate operational consideration section (or into the
> security consideration section instead).
> >
> > "
> > - Operational Considerations
> >
> > The use of CWTs with proof-of-possession keys requires additional
> > information to be shared between the involved parties in order to
> > ensure correct processing. The recipient needs to be able to use
> > credentials to verify the authenticity, integrity and potentially the
> confidentiality of the CWT and its content. This requires the recipient to
> know information about the issuer.
> > Like-wise there needs to be an upfront agreement between the issuer
> > and the recipient about the claims that need to be present and what
> degree of trust can be put into those.
> >
> > When an issuer creates a CWT containing a key id claim, it needs to
> > make sure that it does not issue another CWT containing the same key
> > id with a different content, or for a different subject, within the
> > lifetime of the CWTs, unless intentionally desired. Failure to do so may
> allow one party to impersonate another party with the potential to gain
> additional privileges.
> > "
> 
> When would this be "intentionally desired"?  It seems like there would be
> better ways to share authorization between parties than to issue such
> duplicate CWTs.

One case where this is desired is if you issue a second CWT with additional
permissions for a client and you want to tie it to the same key.  You could
either duplicate the key or just reference it by ID.

Jim

> 
> -Ben

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02

[Jim Schaad]

No not really, Hannes's language is much closer to what I am looking for.  I
don't care if they are different kinds of CWTs.  I care about impersonation.

> -Original Message-
> From: Mike Jones 
> Sent: Friday, June 22, 2018 10:44 PM
> To: Jim Schaad ; Hannes Tschofenig
> ; draft-ietf-ace-cwt-proof-of-
> possess...@ietf.org
> Cc: ace@ietf.org
> Subject: RE: Key IDs ... RE: [Ace] WGLC on draft-ietf-ace-cwt-proof-of-
> possession-02
> 
> I think you're looking for language something along these lines, right
Jim?
> 
> "Likewise, if PoP keys are used for multiple different kinds of CWTs in an
> application and the PoP keys are identified by Key IDs, care must be taken
to
> keep the keys for the different kinds of CWTs segregated so that an
attacker
> cannot cause the wrong PoP key to be used by using a valid Key ID for the
> wrong kind of CWT."
> 
>   -- Mike
> 
> -Original Message-
> From: Jim Schaad 
> Sent: Friday, June 22, 2018 7:59 AM
> To: Hannes Tschofenig ; Mike Jones
> ; draft-ietf-ace-cwt-proof-of-
> possess...@ietf.org
> Cc: ace@ietf.org
> Subject: RE: Key IDs ... RE: [Ace] WGLC on draft-ietf-ace-cwt-proof-of-
> possession-02
> 
> That language works if you assume that there is only one CWT that an RS
will
> look to.  If there are multiple CWTs then one needs coordination language
> between them.
> 
> > -Original Message-
> > From: Hannes Tschofenig 
> > Sent: Friday, June 22, 2018 6:36 AM
> > To: Jim Schaad ; 'Mike Jones'
> > ; draft-ietf-ace-cwt-proof-of-
> > possess...@ietf.org
> > Cc: ace@ietf.org
> > Subject: Key IDs ... RE: [Ace] WGLC on draft-ietf-ace-cwt-proof-of-
> > possession-02
> >
> > Hi Jim,
> >
> > I would like to comment on this issue.
> >
> > -
> > > > 14.  I have real problems w/ the use of a KID for POP
> > > > identification.  It
> > may
> > > identify the wrong key or, if used for granting access, may have
> > > problems
> > w/
> > > identity collisions.  These need to be spelt out someplace to help
> > > people tracking down questions of why can't I verify w/ this CWT, I
> > > know it's
> > right.
> > >
> > > The Key ID is a hint to help identify which PoP key to use.  Yes, if
> > > a Key
> > ID is
> > > sent that doesn't correspond to the right PoP key, failures may occur.
> > > I
> > view
> > > that as usage bug - not a protocol problem.  If keys aren't
> > > consistently
> > known
> > > and identified by both parties, there are lots of things that can go
> > wrong, and
> > > this is only one such instance.  That said, I can try to say
> > > something
> > about the
> > > need for keys to be consistently and known by both parties, if you
> > > think
> > that
> > > would help.
> >
> > > My problem is that if there are two different people with the same
> > > Key ID,
> > either intentionally or unintentionally, then using the key ID to
> > identify
> the
> > key may allow the other person to masquerade as the first person.  I
> > am unworried about the instance of a failure to get a key based on a key
id.
> > That is not the problem you are proposing to address.
> >
> > -
> >
> > I think we should document this issue. Here is some text proposal that
> could
> > go into a separate operational consideration section (or into the
> > security consideration section instead).
> >
> > "
> > - Operational Considerations
> >
> > The use of CWTs with proof-of-possession keys requires additional
> > information to be shared between the involved parties in order to
> > ensure correct processing. The recipient needs to be able to use
> > credentials to
> verify
> > the authenticity, integrity and potentially the confidentiality of the
> > CWT
> and
> > its content. This requires the recipient to know information about the
> issuer.
> > Like-wise there needs to be an upfront agreement between the issuer
> > and the recipient about the claims that need to be present and what
> > degree of trust can be put into those.
> >
> > When an issuer creates a CWT containing a key id claim, it needs to
> > make sure that it does not issue another CWT containing the same key
> > id with a different content, or for a different subject, within the
> > lifetime of the
> CWTs,
> > unless intentionally desired. Failure to do so may allow one party to
> > impersonate another party with the potential to gain additional
> privileges.
> > "
> >
> >
> > Ciao
> > Hannes
> >
> > IMPORTANT NOTICE: The contents of this email and any attachments are
> > confidential and may also be privileged. If you are not the intended
> recipient,
> > please notify the sender immediately and do not disclose the contents
> > to
> any
> > other person, use it for any purpose, or store or copy the information
> > in
> any
> > medium. Thank you.


___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02

[Mike Jones]

The sentence I sent was in addition to Hannes language to address the multiple 
CWT case discussed in the thread - not a replacement for it.

-- Mike

-Original Message-
From: Jim Schaad  
Sent: Saturday, June 23, 2018 9:05 AM
To: Mike Jones ; Hannes Tschofenig 
; draft-ietf-ace-cwt-proof-of-possess...@ietf.org
Cc: ace@ietf.org
Subject: RE: Key IDs ... RE: [Ace] WGLC on 
draft-ietf-ace-cwt-proof-of-possession-02

No not really, Hannes's language is much closer to what I am looking for.  I 
don't care if they are different kinds of CWTs.  I care about impersonation.

> -Original Message-
> From: Mike Jones 
> Sent: Friday, June 22, 2018 10:44 PM
> To: Jim Schaad ; Hannes Tschofenig 
> ; draft-ietf-ace-cwt-proof-of- 
> possess...@ietf.org
> Cc: ace@ietf.org
> Subject: RE: Key IDs ... RE: [Ace] WGLC on 
> draft-ietf-ace-cwt-proof-of-
> possession-02
> 
> I think you're looking for language something along these lines, right
Jim?
> 
> "Likewise, if PoP keys are used for multiple different kinds of CWTs 
> in an application and the PoP keys are identified by Key IDs, care 
> must be taken
to
> keep the keys for the different kinds of CWTs segregated so that an
attacker
> cannot cause the wrong PoP key to be used by using a valid Key ID for 
> the wrong kind of CWT."
> 
>   -- Mike
> 
> -Original Message-
> From: Jim Schaad 
> Sent: Friday, June 22, 2018 7:59 AM
> To: Hannes Tschofenig ; Mike Jones 
> ; draft-ietf-ace-cwt-proof-of- 
> possess...@ietf.org
> Cc: ace@ietf.org
> Subject: RE: Key IDs ... RE: [Ace] WGLC on 
> draft-ietf-ace-cwt-proof-of-
> possession-02
> 
> That language works if you assume that there is only one CWT that an 
> RS
will
> look to.  If there are multiple CWTs then one needs coordination 
> language between them.
> 
> > -Original Message-
> > From: Hannes Tschofenig 
> > Sent: Friday, June 22, 2018 6:36 AM
> > To: Jim Schaad ; 'Mike Jones'
> > ; draft-ietf-ace-cwt-proof-of- 
> > possess...@ietf.org
> > Cc: ace@ietf.org
> > Subject: Key IDs ... RE: [Ace] WGLC on draft-ietf-ace-cwt-proof-of-
> > possession-02
> >
> > Hi Jim,
> >
> > I would like to comment on this issue.
> >
> > -
> > > > 14.  I have real problems w/ the use of a KID for POP 
> > > > identification.  It
> > may
> > > identify the wrong key or, if used for granting access, may have 
> > > problems
> > w/
> > > identity collisions.  These need to be spelt out someplace to help 
> > > people tracking down questions of why can't I verify w/ this CWT, 
> > > I know it's
> > right.
> > >
> > > The Key ID is a hint to help identify which PoP key to use.  Yes, 
> > > if a Key
> > ID is
> > > sent that doesn't correspond to the right PoP key, failures may occur.
> > > I
> > view
> > > that as usage bug - not a protocol problem.  If keys aren't 
> > > consistently
> > known
> > > and identified by both parties, there are lots of things that can 
> > > go
> > wrong, and
> > > this is only one such instance.  That said, I can try to say 
> > > something
> > about the
> > > need for keys to be consistently and known by both parties, if you 
> > > think
> > that
> > > would help.
> >
> > > My problem is that if there are two different people with the same 
> > > Key ID,
> > either intentionally or unintentionally, then using the key ID to 
> > identify
> the
> > key may allow the other person to masquerade as the first person.  I 
> > am unworried about the instance of a failure to get a key based on a 
> > key
id.
> > That is not the problem you are proposing to address.
> >
> > -
> >
> > I think we should document this issue. Here is some text proposal 
> > that
> could
> > go into a separate operational consideration section (or into the 
> > security consideration section instead).
> >
> > "
> > - Operational Considerations
> >
> > The use of CWTs with proof-of-possession keys requires additional 
> > information to be shared between the involved parties in order to 
> > ensure correct processing. The recipient needs to be able to use 
> > credentials to
> verify
> > the authenticity, integrity and potentially the confidentiality of 
> > the CWT
> and
> > its content. This requires the recipient to know information about 
> > the
> issuer.
> > Like-wise there needs to be an upfront agreement between the issuer 
> > and the recipient about the claims that need to be present and what 
> > degree of trust can be put into those.
> >
> > When an issuer creates a CWT containing a key id claim, it needs to 
> > make sure that it does not issue another CWT containing the same key 
> > id with a different content, or for a different subject, within the 
> > lifetime of the
> CWTs,
> > unless intentionally desired. Failure to do so may allow one party 
> > to impersonate another party with the potential to gain additional
> privileges.
> > "
> >
> >
> > Ciao
> > Hannes
> >
> > IMPORTANT NOTICE: The contents of this email and any attachments ar

Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02

[Benjamin Kaduk]

On Fri, Jun 22, 2018 at 08:48:35PM +, Mike Jones wrote:
> See my note just now proposing this text to Jim:
> 
> "Likewise, if PoP keys are used for multiple different kinds of CWTs in an 
> application and the PoP keys are identified by Key IDs, care must be taken to 
> keep the keys for the different kinds of CWTs segregated so that an attacker 
> cannot cause the wrong PoP key to be used by using a valid Key ID for the 
> wrong kind of CWT."
> 
> As long as the PoP keys for different contexts are kept segregated, Key ID 
> collisions or reuse cause no problems.

If we trust everyone to implement things properly.  We should probably only
take that risk if we get some other benefit from it, though.  Jim mentioned
(off-list?) a scenario involving giving the same client additional
privileges, and of course we can gain some simplicity savings if we don't
need to enforce global key-id uniqueness (for appropriate values of
"global").  So this may well be the right thing to do; I just don't think
it's without tradeoffs as your text seems to imply.

-Ben

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02

[Jim Schaad]

Thinking things through, I would be more comfortable with something like the
following:

1.  Create a confirmation called 'computed key id'.  This has two basic
values:  What is the computation method?  What is the proof value?  You can
optionally have an unprotected KID value used to filter the set of keys on
the RS down to a reasonable set to enumerate (hopefully one).

2.  For RPK and TLS:  Define a method called hash of SPKI which has a hash
method as a parameter.  Given that this can be computed independently by all
entities based on a Public Key value and it will be unique then you have a
key identifier that will not have collisions independent of who issues the
CWT.

3.  For PSK and TLS:  Define a method which takes some parameters including
the key value, the CWT issuer identity and perhaps some random string and
compute a proof of possession value on the PSK.  

4.  For PSK and OSCORE: Define a similar method the question would be what
the key value is to be used but that can be defined as part of OSCORE

When using the keys for TLS

For RPK the key is carried in the handshake and the server/client can
generate the computed key id and compare it to what the AS distributed.  The
server can identify which CWTs are applicable by either comparison of the
RPKs or the computed key id.  This means you have a high probability that
you will not make a mistake and match to the wrong key.

For PSK the identifier is carried in the handshake which is used to look up
a key value and the handshake is performed.  By matching computed key ids
with the secret value one can ensure to a high probably that only CWTs that
reference the same secret are going to be used for permissions even if they
come from different AS entities.

For OSCORE it is similar, the identifier is used to look up a key value and
by decrypting the CWT the key value is proofed.  You then match computed key
ids in the same manner.

If you really want to have something that is not cryptographically computed
and point to something else, then it makes more sense to me to reference a
CWT issued by the same entity and say "use the same conformation method as
this CWT does".

jim

> -Original Message-
> From: Benjamin Kaduk 
> Sent: Saturday, June 23, 2018 11:30 PM
> To: Mike Jones 
> Cc: Hannes Tschofenig ; Jim Schaad
> ; draft-ietf-ace-cwt-proof-of-possess...@ietf.org;
> ace@ietf.org
> Subject: Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-
> possession-02
> 
> On Fri, Jun 22, 2018 at 08:48:35PM +, Mike Jones wrote:
> > See my note just now proposing this text to Jim:
> >
> > "Likewise, if PoP keys are used for multiple different kinds of CWTs in
an
> application and the PoP keys are identified by Key IDs, care must be taken
to
> keep the keys for the different kinds of CWTs segregated so that an
attacker
> cannot cause the wrong PoP key to be used by using a valid Key ID for the
> wrong kind of CWT."
> >
> > As long as the PoP keys for different contexts are kept segregated, Key
ID
> collisions or reuse cause no problems.
> 
> If we trust everyone to implement things properly.  We should probably
only
> take that risk if we get some other benefit from it, though.  Jim
mentioned
> (off-list?) a scenario involving giving the same client additional
privileges, and
> of course we can gain some simplicity savings if we don't need to enforce
> global key-id uniqueness (for appropriate values of "global").  So this
may
> well be the right thing to do; I just don't think it's without tradeoffs
as your
> text seems to imply.
> 
> -Ben

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02

[Ludwig Seitz]

On 2018-06-22 15:36, Hannes Tschofenig wrote:

Hi Jim,

I would like to comment on this issue.

-

14.  I have real problems w/ the use of a KID for POP identification.  It

may

identify the wrong key or, if used for granting access, may have problems

w/

identity collisions.  These need to be spelt out someplace to help people
tracking down questions of why can't I verify w/ this CWT, I know it's

right.



I just wanted to note that we inherited that issue from RFC 7800, does 
someone recall what the security considerations were in that case?



Perhaps a variant of Hannes' text comes closer to what Jim is looking for:

"
- Operational Considerations



When an issuer creates a CWT containing a key id claim, it is not 
acceptable to issue another CWT containing the same key id, unless they 
both are for the same subject and for the same audience (e.g. providing 
additional privileges for the subject).

"

/Ludwig

--
Ludwig Seitz, PhD
Security Lab, RISE SICS
Phone +46(0)70-349 92 51

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02

[Hannes Tschofenig]

Ben,

I was wondering whether the situation is any different in Kerberos. If the KDC 
creates tickets with a session key included then it needs to make sure that it 
does not create the same symmetric key for different usages.
The key in the Kerberos ticket is similar to the PoP key in our discussion.

Are we aware of key collision in Kerberos?

Ciao
Hannes

-Original Message-
From: Benjamin Kaduk [mailto:ka...@mit.edu]
Sent: 23 June 2018 23:30
To: Mike Jones
Cc: Hannes Tschofenig; Jim Schaad; 
draft-ietf-ace-cwt-proof-of-possess...@ietf.org; ace@ietf.org
Subject: Re: [Ace] Key IDs ... RE: WGLC on 
draft-ietf-ace-cwt-proof-of-possession-02

On Fri, Jun 22, 2018 at 08:48:35PM +, Mike Jones wrote:
> See my note just now proposing this text to Jim:
>
> "Likewise, if PoP keys are used for multiple different kinds of CWTs in an 
> application and the PoP keys are identified by Key IDs, care must be taken to 
> keep the keys for the different kinds of CWTs segregated so that an attacker 
> cannot cause the wrong PoP key to be used by using a valid Key ID for the 
> wrong kind of CWT."
>
> As long as the PoP keys for different contexts are kept segregated, Key ID 
> collisions or reuse cause no problems.

If we trust everyone to implement things properly.  We should probably only
take that risk if we get some other benefit from it, though.  Jim mentioned
(off-list?) a scenario involving giving the same client additional
privileges, and of course we can gain some simplicity savings if we don't
need to enforce global key-id uniqueness (for appropriate values of
"global").  So this may well be the right thing to do; I just don't think
it's without tradeoffs as your text seems to imply.

-Ben
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02

[Benjamin Kaduk]

On Tue, Jun 26, 2018 at 08:53:57AM +, Hannes Tschofenig wrote:
> Ben,
> 
> I was wondering whether the situation is any different in Kerberos. If the 
> KDC creates tickets with a session key included then it needs to make sure 
> that it does not create the same symmetric key for different usages.
> The key in the Kerberos ticket is similar to the PoP key in our discussion.
> 
> Are we aware of key collision in Kerberos?

I don't believe key collision is an issue in Kerberos.  Long-term keys
(which are not what we're talking about here) are identified by a principal
name, encryption type, and version number.  Session keys that are contained
within tickets (and returned to the client in the KDC-REP) are random, so
even if we are only using the birthday bound we're still in pretty good
shape.  The modern enctypes tend to use subsession keys generated by the
client and/or server as well as the KDC-generated session key, which
provides further binding to the current session.

Does that answer your question?

-Ben

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02

[Hannes Tschofenig]

It does answer my question, Ben.

This begs the question why the collision of session keys is suddenly a problem 
in the ACE context when it wasn't a problem so far. Something must have changed.

Ciao
Hannes


-Original Message-
From: Benjamin Kaduk [mailto:ka...@mit.edu]
Sent: 26 June 2018 17:00
To: Hannes Tschofenig
Cc: Mike Jones; Jim Schaad; draft-ietf-ace-cwt-proof-of-possess...@ietf.org; 
ace@ietf.org
Subject: Re: [Ace] Key IDs ... RE: WGLC on 
draft-ietf-ace-cwt-proof-of-possession-02

On Tue, Jun 26, 2018 at 08:53:57AM +, Hannes Tschofenig wrote:
> Ben,
>
> I was wondering whether the situation is any different in Kerberos. If the 
> KDC creates tickets with a session key included then it needs to make sure 
> that it does not create the same symmetric key for different usages.
> The key in the Kerberos ticket is similar to the PoP key in our discussion.
>
> Are we aware of key collision in Kerberos?

I don't believe key collision is an issue in Kerberos.  Long-term keys
(which are not what we're talking about here) are identified by a principal
name, encryption type, and version number.  Session keys that are contained
within tickets (and returned to the client in the KDC-REP) are random, so
even if we are only using the birthday bound we're still in pretty good
shape.  The modern enctypes tend to use subsession keys generated by the
client and/or server as well as the KDC-generated session key, which
provides further binding to the current session.

Does that answer your question?

-Ben
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02

[Benjamin Kaduk]

I thought we were worried about collision of key *identifiers*, which were
not necessarily raw keys or hashes thereof.  But it's possible I was not
paying enough attention and got confused.

-Ben

On Tue, Jun 26, 2018 at 03:12:52PM +, Hannes Tschofenig wrote:
> It does answer my question, Ben.
> 
> This begs the question why the collision of session keys is suddenly a 
> problem in the ACE context when it wasn't a problem so far. Something must 
> have changed.
> 
> Ciao
> Hannes
> 
> 
> -Original Message-
> From: Benjamin Kaduk [mailto:ka...@mit.edu]
> Sent: 26 June 2018 17:00
> To: Hannes Tschofenig
> Cc: Mike Jones; Jim Schaad; draft-ietf-ace-cwt-proof-of-possess...@ietf.org; 
> ace@ietf.org
> Subject: Re: [Ace] Key IDs ... RE: WGLC on 
> draft-ietf-ace-cwt-proof-of-possession-02
> 
> On Tue, Jun 26, 2018 at 08:53:57AM +, Hannes Tschofenig wrote:
> > Ben,
> >
> > I was wondering whether the situation is any different in Kerberos. If the 
> > KDC creates tickets with a session key included then it needs to make sure 
> > that it does not create the same symmetric key for different usages.
> > The key in the Kerberos ticket is similar to the PoP key in our discussion.
> >
> > Are we aware of key collision in Kerberos?
> 
> I don't believe key collision is an issue in Kerberos.  Long-term keys
> (which are not what we're talking about here) are identified by a principal
> name, encryption type, and version number.  Session keys that are contained
> within tickets (and returned to the client in the KDC-REP) are random, so
> even if we are only using the birthday bound we're still in pretty good
> shape.  The modern enctypes tend to use subsession keys generated by the
> client and/or server as well as the KDC-generated session key, which
> provides further binding to the current session.
> 
> Does that answer your question?
> 
> -Ben
> IMPORTANT NOTICE: The contents of this email and any attachments are 
> confidential and may also be privileged. If you are not the intended 
> recipient, please notify the sender immediately and do not disclose the 
> contents to any other person, use it for any purpose, or store or copy the 
> information in any medium. Thank you.

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02

[Hannes Tschofenig]

Hi Jim,

you are essentially proposing that we should not directly use the key id that 
is in the CWT-PoP but rather use it as input in a key derivation function. The 
details of that key derivation function are specified outside the CWT-POP 
document and most likely in the context of the various profiles.
Your proposals below suggest to use, among other things, the session key as 
input to that function. That sounds pretty straight forward but raises the 
question why we fail to trust the implementer to create random key ids but then 
still trust them to create random keys.

That's fine for me nevertheless.

Ciao
Hannes

-Original Message-
From: Jim Schaad [mailto:i...@augustcellars.com]
Sent: 24 June 2018 10:15
To: 'Benjamin Kaduk'; 'Mike Jones'
Cc: Hannes Tschofenig; draft-ietf-ace-cwt-proof-of-possess...@ietf.org; 
ace@ietf.org
Subject: RE: [Ace] Key IDs ... RE: WGLC on 
draft-ietf-ace-cwt-proof-of-possession-02

Thinking things through, I would be more comfortable with something like the
following:

1.  Create a confirmation called 'computed key id'.  This has two basic
values:  What is the computation method?  What is the proof value?  You can
optionally have an unprotected KID value used to filter the set of keys on
the RS down to a reasonable set to enumerate (hopefully one).

2.  For RPK and TLS:  Define a method called hash of SPKI which has a hash
method as a parameter.  Given that this can be computed independently by all
entities based on a Public Key value and it will be unique then you have a
key identifier that will not have collisions independent of who issues the
CWT.

3.  For PSK and TLS:  Define a method which takes some parameters including
the key value, the CWT issuer identity and perhaps some random string and
compute a proof of possession value on the PSK.

4.  For PSK and OSCORE: Define a similar method the question would be what
the key value is to be used but that can be defined as part of OSCORE

When using the keys for TLS

For RPK the key is carried in the handshake and the server/client can
generate the computed key id and compare it to what the AS distributed.  The
server can identify which CWTs are applicable by either comparison of the
RPKs or the computed key id.  This means you have a high probability that
you will not make a mistake and match to the wrong key.

For PSK the identifier is carried in the handshake which is used to look up
a key value and the handshake is performed.  By matching computed key ids
with the secret value one can ensure to a high probably that only CWTs that
reference the same secret are going to be used for permissions even if they
come from different AS entities.

For OSCORE it is similar, the identifier is used to look up a key value and
by decrypting the CWT the key value is proofed.  You then match computed key
ids in the same manner.

If you really want to have something that is not cryptographically computed
and point to something else, then it makes more sense to me to reference a
CWT issued by the same entity and say "use the same conformation method as
this CWT does".

jim

> -Original Message-
> From: Benjamin Kaduk 
> Sent: Saturday, June 23, 2018 11:30 PM
> To: Mike Jones 
> Cc: Hannes Tschofenig ; Jim Schaad
> ; draft-ietf-ace-cwt-proof-of-possess...@ietf.org;
> ace@ietf.org
> Subject: Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-
> possession-02
>
> On Fri, Jun 22, 2018 at 08:48:35PM +, Mike Jones wrote:
> > See my note just now proposing this text to Jim:
> >
> > "Likewise, if PoP keys are used for multiple different kinds of CWTs in
an
> application and the PoP keys are identified by Key IDs, care must be taken
to
> keep the keys for the different kinds of CWTs segregated so that an
attacker
> cannot cause the wrong PoP key to be used by using a valid Key ID for the
> wrong kind of CWT."
> >
> > As long as the PoP keys for different contexts are kept segregated, Key
ID
> collisions or reuse cause no problems.
>
> If we trust everyone to implement things properly.  We should probably
only
> take that risk if we get some other benefit from it, though.  Jim
mentioned
> (off-list?) a scenario involving giving the same client additional
privileges, and
> of course we can gain some simplicity savings if we don't need to enforce
> global key-id uniqueness (for appropriate values of "global").  So this
may
> well be the right thing to do; I just don't think it's without tradeoffs
as your
> text seems to imply.
>
> -Ben

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02

[Hannes Tschofenig]

Hi Ben,

You are right. We were talking about the key identifiers.

Let me still stick with the Kerberos example. In that context this would mean 
that the KDC stores multiple accounts in the database that point to the same 
principal name. Have you seen that happening?
Re-using the same principle name over time as identifier get recycle when users 
get retired or otherwise leave the system might be an option. Is this a more 
likely?

As you see I am trying to find some examples of vulnerabilities in existing 
systems and I am having a hard time.

Ciao
Hannes

-Original Message-
From: Benjamin Kaduk [mailto:ka...@mit.edu]
Sent: 26 June 2018 17:14
To: Hannes Tschofenig
Cc: Mike Jones; Jim Schaad; draft-ietf-ace-cwt-proof-of-possess...@ietf.org; 
ace@ietf.org
Subject: Re: [Ace] Key IDs ... RE: WGLC on 
draft-ietf-ace-cwt-proof-of-possession-02

I thought we were worried about collision of key *identifiers*, which were
not necessarily raw keys or hashes thereof.  But it's possible I was not
paying enough attention and got confused.

-Ben

On Tue, Jun 26, 2018 at 03:12:52PM +, Hannes Tschofenig wrote:
> It does answer my question, Ben.
>
> This begs the question why the collision of session keys is suddenly a 
> problem in the ACE context when it wasn't a problem so far. Something must 
> have changed.
>
> Ciao
> Hannes
>
>
> -Original Message-
> From: Benjamin Kaduk [mailto:ka...@mit.edu]
> Sent: 26 June 2018 17:00
> To: Hannes Tschofenig
> Cc: Mike Jones; Jim Schaad; draft-ietf-ace-cwt-proof-of-possess...@ietf.org; 
> ace@ietf.org
> Subject: Re: [Ace] Key IDs ... RE: WGLC on 
> draft-ietf-ace-cwt-proof-of-possession-02
>
> On Tue, Jun 26, 2018 at 08:53:57AM +, Hannes Tschofenig wrote:
> > Ben,
> >
> > I was wondering whether the situation is any different in Kerberos. If the 
> > KDC creates tickets with a session key included then it needs to make sure 
> > that it does not create the same symmetric key for different usages.
> > The key in the Kerberos ticket is similar to the PoP key in our discussion.
> >
> > Are we aware of key collision in Kerberos?
>
> I don't believe key collision is an issue in Kerberos.  Long-term keys
> (which are not what we're talking about here) are identified by a principal
> name, encryption type, and version number.  Session keys that are contained
> within tickets (and returned to the client in the KDC-REP) are random, so
> even if we are only using the birthday bound we're still in pretty good
> shape.  The modern enctypes tend to use subsession keys generated by the
> client and/or server as well as the KDC-generated session key, which
> provides further binding to the current session.
>
> Does that answer your question?
>
> -Ben
> IMPORTANT NOTICE: The contents of this email and any attachments are 
> confidential and may also be privileged. If you are not the intended 
> recipient, please notify the sender immediately and do not disclose the 
> contents to any other person, use it for any purpose, or store or copy the 
> information in any medium. Thank you.
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02

[Benjamin Kaduk]

In Kerberos, the full principal name includes a realm name as well as the
name of the principal itself; this realm would be roughly analogous to an
OAuth Issuer.  There are plenty of case where there are collisions between
the non-realm portion of the Kerberos principal; for example, I control all
of ka...@athena.mit.edu, ka...@zone.mit.edu, and ka...@grand.central.org 
but apply different levels of trust and privilege to them.   A more
poignant example would be the case of b...@freebsd.org and
b...@athena.mit.edu, of which I control the former but not the latter.
There is some potential for actual issues when the GSSAPI is involved,
since the standard way to pick a server ("GSS acceptor") to talk to is to
generate a host-based principal name, e.g., service="host" and
hostname="ssh.dialup.example.com", which does not include Kerberos realm
information (since the GSSAPI does not have such a concept).  The Kerberos
library uses the hostname and some mapping rules/heuristics to pick a
Kerberos realm to use for ssh.dialup.example.com, but if the heuristic is
wrong for a particular case, an attacker could acquire that service
principal in the "wrong" realm, MITM, and appear to make the client connect
successfully.  (Non-MITM'd connections would fail, though, so this is
likely to be detected quickly as a configuration error.)

Within a single realm (and database), there is equivalence between account
and principal name, though there are some occurrences of re-use of the same
principal name when users or machines leave the system and reenter.  There
is usually a broad time separtation for that, though.

-Ben

On Tue, Jun 26, 2018 at 04:08:42PM +, Hannes Tschofenig wrote:
> Hi Ben,
> 
> You are right. We were talking about the key identifiers.
> 
> Let me still stick with the Kerberos example. In that context this would mean 
> that the KDC stores multiple accounts in the database that point to the same 
> principal name. Have you seen that happening?
> Re-using the same principle name over time as identifier get recycle when 
> users get retired or otherwise leave the system might be an option. Is this a 
> more likely?
> 
> As you see I am trying to find some examples of vulnerabilities in existing 
> systems and I am having a hard time.
> 
> Ciao
> Hannes
> 
> -Original Message-
> From: Benjamin Kaduk [mailto:ka...@mit.edu]
> Sent: 26 June 2018 17:14
> To: Hannes Tschofenig
> Cc: Mike Jones; Jim Schaad; draft-ietf-ace-cwt-proof-of-possess...@ietf.org; 
> ace@ietf.org
> Subject: Re: [Ace] Key IDs ... RE: WGLC on 
> draft-ietf-ace-cwt-proof-of-possession-02
> 
> I thought we were worried about collision of key *identifiers*, which were
> not necessarily raw keys or hashes thereof.  But it's possible I was not
> paying enough attention and got confused.
> 
> -Ben
> 
> On Tue, Jun 26, 2018 at 03:12:52PM +, Hannes Tschofenig wrote:
> > It does answer my question, Ben.
> >
> > This begs the question why the collision of session keys is suddenly a 
> > problem in the ACE context when it wasn't a problem so far. Something must 
> > have changed.
> >
> > Ciao
> > Hannes
> >
> >
> > -Original Message-
> > From: Benjamin Kaduk [mailto:ka...@mit.edu]
> > Sent: 26 June 2018 17:00
> > To: Hannes Tschofenig
> > Cc: Mike Jones; Jim Schaad; 
> > draft-ietf-ace-cwt-proof-of-possess...@ietf.org; ace@ietf.org
> > Subject: Re: [Ace] Key IDs ... RE: WGLC on 
> > draft-ietf-ace-cwt-proof-of-possession-02
> >
> > On Tue, Jun 26, 2018 at 08:53:57AM +, Hannes Tschofenig wrote:
> > > Ben,
> > >
> > > I was wondering whether the situation is any different in Kerberos. If 
> > > the KDC creates tickets with a session key included then it needs to make 
> > > sure that it does not create the same symmetric key for different usages.
> > > The key in the Kerberos ticket is similar to the PoP key in our 
> > > discussion.
> > >
> > > Are we aware of key collision in Kerberos?
> >
> > I don't believe key collision is an issue in Kerberos.  Long-term keys
> > (which are not what we're talking about here) are identified by a principal
> > name, encryption type, and version number.  Session keys that are contained
> > within tickets (and returned to the client in the KDC-REP) are random, so
> > even if we are only using the birthday bound we're still in pretty good
> > shape.  The modern enctypes tend to use subsession keys generated by the
> > client and/or server as well as the KDC-generated session key, which
> > provides further binding to the current session.
> >
> > Does that 

Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02

[Jim Schaad]

No Ben, you are 100% correct.  This is about identifiers and not session
keys.

> -Original Message-
> From: Benjamin Kaduk 
> Sent: Tuesday, June 26, 2018 5:14 PM
> To: Hannes Tschofenig 
> Cc: Mike Jones ; Jim Schaad
> ; draft-ietf-ace-cwt-proof-of-possess...@ietf.org;
> ace@ietf.org
> Subject: Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-
> possession-02
> 
> I thought we were worried about collision of key *identifiers*, which were
> not necessarily raw keys or hashes thereof.  But it's possible I was not
paying
> enough attention and got confused.
> 
> -Ben
> 
> On Tue, Jun 26, 2018 at 03:12:52PM +, Hannes Tschofenig wrote:
> > It does answer my question, Ben.
> >
> > This begs the question why the collision of session keys is suddenly a
> problem in the ACE context when it wasn't a problem so far. Something must
> have changed.
> >
> > Ciao
> > Hannes
> >
> >
> > -Original Message-
> > From: Benjamin Kaduk [mailto:ka...@mit.edu]
> > Sent: 26 June 2018 17:00
> > To: Hannes Tschofenig
> > Cc: Mike Jones; Jim Schaad;
> > draft-ietf-ace-cwt-proof-of-possess...@ietf.org; ace@ietf.org
> > Subject: Re: [Ace] Key IDs ... RE: WGLC on
> > draft-ietf-ace-cwt-proof-of-possession-02
> >
> > On Tue, Jun 26, 2018 at 08:53:57AM +, Hannes Tschofenig wrote:
> > > Ben,
> > >
> > > I was wondering whether the situation is any different in Kerberos. If
the
> KDC creates tickets with a session key included then it needs to make sure
> that it does not create the same symmetric key for different usages.
> > > The key in the Kerberos ticket is similar to the PoP key in our
discussion.
> > >
> > > Are we aware of key collision in Kerberos?
> >
> > I don't believe key collision is an issue in Kerberos.  Long-term keys
> > (which are not what we're talking about here) are identified by a
> > principal name, encryption type, and version number.  Session keys
> > that are contained within tickets (and returned to the client in the
> > KDC-REP) are random, so even if we are only using the birthday bound
> > we're still in pretty good shape.  The modern enctypes tend to use
> > subsession keys generated by the client and/or server as well as the
> > KDC-generated session key, which provides further binding to the current
> session.
> >
> > Does that answer your question?
> >
> > -Ben
> > IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
recipient,
> please notify the sender immediately and do not disclose the contents to
any
> other person, use it for any purpose, or store or copy the information in
any
> medium. Thank you.

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02

[Jim Schaad]

Hannes,

My worry is not about implementers getting this correct and picking random
key ids.  My worry is about an attacker seeing the key id of somebody and
trying to use it either with the same or a different AS and getting a key
and then getting permissions associated with the initial key that they
should not be doing.

This is about an attack not about getting things to generally work right.

Jim


> -Original Message-
> From: Hannes Tschofenig 
> Sent: Tuesday, June 26, 2018 6:09 PM
> To: Jim Schaad ; 'Benjamin Kaduk'
> ; 'Mike Jones' 
> Cc: draft-ietf-ace-cwt-proof-of-possess...@ietf.org; ace@ietf.org
> Subject: RE: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-
> possession-02
> 
> Hi Jim,
> 
> you are essentially proposing that we should not directly use the key id
that
> is in the CWT-PoP but rather use it as input in a key derivation function.
The
> details of that key derivation function are specified outside the CWT-POP
> document and most likely in the context of the various profiles.
> Your proposals below suggest to use, among other things, the session key
as
> input to that function. That sounds pretty straight forward but raises the
> question why we fail to trust the implementer to create random key ids but
> then still trust them to create random keys.
> 
> That's fine for me nevertheless.
> 
> Ciao
> Hannes
> 
> -Original Message-
> From: Jim Schaad [mailto:i...@augustcellars.com]
> Sent: 24 June 2018 10:15
> To: 'Benjamin Kaduk'; 'Mike Jones'
> Cc: Hannes Tschofenig; draft-ietf-ace-cwt-proof-of-possess...@ietf.org;
> ace@ietf.org
> Subject: RE: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-
> possession-02
> 
> Thinking things through, I would be more comfortable with something like
> the
> following:
> 
> 1.  Create a confirmation called 'computed key id'.  This has two basic
> values:  What is the computation method?  What is the proof value?  You
can
> optionally have an unprotected KID value used to filter the set of keys on
the
> RS down to a reasonable set to enumerate (hopefully one).
> 
> 2.  For RPK and TLS:  Define a method called hash of SPKI which has a hash
> method as a parameter.  Given that this can be computed independently by
> all entities based on a Public Key value and it will be unique then you
have a
> key identifier that will not have collisions independent of who issues the
> CWT.
> 
> 3.  For PSK and TLS:  Define a method which takes some parameters
including
> the key value, the CWT issuer identity and perhaps some random string and
> compute a proof of possession value on the PSK.
> 
> 4.  For PSK and OSCORE: Define a similar method the question would be what
> the key value is to be used but that can be defined as part of OSCORE
> 
> When using the keys for TLS
> 
> For RPK the key is carried in the handshake and the server/client can
> generate the computed key id and compare it to what the AS distributed.
> The server can identify which CWTs are applicable by either comparison of
> the RPKs or the computed key id.  This means you have a high probability
> that you will not make a mistake and match to the wrong key.
> 
> For PSK the identifier is carried in the handshake which is used to look
up a
> key value and the handshake is performed.  By matching computed key ids
> with the secret value one can ensure to a high probably that only CWTs
that
> reference the same secret are going to be used for permissions even if
they
> come from different AS entities.
> 
> For OSCORE it is similar, the identifier is used to look up a key value
and by
> decrypting the CWT the key value is proofed.  You then match computed key
> ids in the same manner.
> 
> If you really want to have something that is not cryptographically
computed
> and point to something else, then it makes more sense to me to reference a
> CWT issued by the same entity and say "use the same conformation method
> as this CWT does".
> 
> jim
> 
> > -Original Message-
> > From: Benjamin Kaduk 
> > Sent: Saturday, June 23, 2018 11:30 PM
> > To: Mike Jones 
> > Cc: Hannes Tschofenig ; Jim Schaad
> > ;
> > draft-ietf-ace-cwt-proof-of-possess...@ietf.org;
> > ace@ietf.org
> > Subject: Re: [Ace] Key IDs ... RE: WGLC on
> > draft-ietf-ace-cwt-proof-of-
> > possession-02
> >
> > On Fri, Jun 22, 2018 at 08:48:35PM +, Mike Jones wrote:
> > > See my note just now proposing this text to Jim:
> > >
> > > "Likewise, if PoP keys are used for multiple different kinds of CWTs
> > > in
> an
> > application and the PoP keys are identif

Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02

[Samuel Erdtman]

Jim, are you saying that if the client can pick the key identifier and if
it has seen a key identifier of another client it could request a PoP token
with the observed key-id and the observed subject but with an new key.
I guess this is a potential scenario that could be worth mentioning in
security considerations.

If we look at ACE-OAuth there are as far as I can tell a few things that
makes this a hard attack to do.

When the client makes the token request it is authenticated.

And with the subject being the authenticated client cannot control what
goes into the cwt as subject

Since the cwt with the PoP key is signed there is no way for the attacking
client to retro-fit the token to suit its needs e.g. change subject or
key-id.

Finally I think it is preferable if the server selects key identifier.

Best regards
//Samuel



On Tue, 26 Jun 2018 at 18:57, Jim Schaad  wrote:

> Hannes,
>
> My worry is not about implementers getting this correct and picking random
> key ids.  My worry is about an attacker seeing the key id of somebody and
> trying to use it either with the same or a different AS and getting a key
> and then getting permissions associated with the initial key that they
> should not be doing.
>
> This is about an attack not about getting things to generally work right.
>
> Jim
>
>
> > -Original Message-
> > From: Hannes Tschofenig 
> > Sent: Tuesday, June 26, 2018 6:09 PM
> > To: Jim Schaad ; 'Benjamin Kaduk'
> > ; 'Mike Jones' 
> > Cc: draft-ietf-ace-cwt-proof-of-possess...@ietf.org; ace@ietf.org
> > Subject: RE: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-
> > possession-02
> >
> > Hi Jim,
> >
> > you are essentially proposing that we should not directly use the key id
> that
> > is in the CWT-PoP but rather use it as input in a key derivation
> function.
> The
> > details of that key derivation function are specified outside the CWT-POP
> > document and most likely in the context of the various profiles.
> > Your proposals below suggest to use, among other things, the session key
> as
> > input to that function. That sounds pretty straight forward but raises
> the
> > question why we fail to trust the implementer to create random key ids
> but
> > then still trust them to create random keys.
> >
> > That's fine for me nevertheless.
> >
> > Ciao
> > Hannes
> >
> > -Original Message-----
> > From: Jim Schaad [mailto:i...@augustcellars.com]
> > Sent: 24 June 2018 10:15
> > To: 'Benjamin Kaduk'; 'Mike Jones'
> > Cc: Hannes Tschofenig; draft-ietf-ace-cwt-proof-of-possess...@ietf.org;
> > ace@ietf.org
> > Subject: RE: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-
> > possession-02
> >
> > Thinking things through, I would be more comfortable with something like
> > the
> > following:
> >
> > 1.  Create a confirmation called 'computed key id'.  This has two basic
> > values:  What is the computation method?  What is the proof value?  You
> can
> > optionally have an unprotected KID value used to filter the set of keys
> on
> the
> > RS down to a reasonable set to enumerate (hopefully one).
> >
> > 2.  For RPK and TLS:  Define a method called hash of SPKI which has a
> hash
> > method as a parameter.  Given that this can be computed independently by
> > all entities based on a Public Key value and it will be unique then you
> have a
> > key identifier that will not have collisions independent of who issues
> the
> > CWT.
> >
> > 3.  For PSK and TLS:  Define a method which takes some parameters
> including
> > the key value, the CWT issuer identity and perhaps some random string and
> > compute a proof of possession value on the PSK.
> >
> > 4.  For PSK and OSCORE: Define a similar method the question would be
> what
> > the key value is to be used but that can be defined as part of OSCORE
> >
> > When using the keys for TLS
> >
> > For RPK the key is carried in the handshake and the server/client can
> > generate the computed key id and compare it to what the AS distributed.
> > The server can identify which CWTs are applicable by either comparison of
> > the RPKs or the computed key id.  This means you have a high probability
> > that you will not make a mistake and match to the wrong key.
> >
> > For PSK the identifier is carried in the handshake which is used to look
> up a
> > key value and the handshake is performed.  By matching computed key ids
> > with the secret value one can ensure to a high probably that only CWTs
&g

Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02

[Jim Schaad]

 

 

From: Samuel Erdtman  
Sent: Wednesday, June 27, 2018 8:18 AM
To: Jim Schaad 
Cc: Hannes Tschofenig ; Benjamin Kaduk 
; Mike Jones ; 
draft-ietf-ace-cwt-proof-of-possess...@ietf.org; ace@ietf.org
Subject: Re: [Ace] Key IDs ... RE: WGLC on 
draft-ietf-ace-cwt-proof-of-possession-02

 

Jim, are you saying that if the client can pick the key identifier and if it 
has seen a key identifier of another client it could request a PoP token with 
the observed key-id and the observed subject but with an new key. 
I guess this is a potential scenario that could be worth mentioning in security 
considerations.

[JLS] No I am not assuming that the observed subject is also chosen by the 
attacker, just the observed key-id.

If we look at ACE-OAuth there are as far as I can tell a few things that makes 
this a hard attack to do.

When the client makes the token request it is authenticated.

[JLS] Unclear why this is relevant.  I am asking for this new token as myself.

And with the subject being the authenticated client cannot control what goes 
into the cwt as subject

[JLS] You are making an assumption that a) the subject is actually going to be 
populated rather than be left empty and thus be anonymous and 2) that the 
resource server is going to make any enforcement based on the subject.  I 
expect it to be done based on audience and scope only.

Since the cwt with the PoP key is signed there is no way for the attacking 
client to retro-fit the token to suit its needs e.g. change subject or key-id.

[JLS] I am asking for a new token not trying to modify an existing token so 
this is not especially relevant.


Finally I think it is preferable if the server selects key identifier. 

[JLS] I would agree, however if you have two AS that are operating in the same 
authorization range and are not tightly linked then this is not easy for doing 
an additional privilege token where the POP is identified by the KID.  This is 
even harder if an RS is going to allow two different AS from different scopes 
to be authoritative as they would never coordinate together.



Best regards
//Samuel




On Tue, 26 Jun 2018 at 18:57, Jim Schaad mailto:i...@augustcellars.com> > wrote:

Hannes,

My worry is not about implementers getting this correct and picking random
key ids.  My worry is about an attacker seeing the key id of somebody and
trying to use it either with the same or a different AS and getting a key
and then getting permissions associated with the initial key that they
should not be doing.

This is about an attack not about getting things to generally work right.

Jim


> -Original Message-
> From: Hannes Tschofenig  <mailto:hannes.tschofe...@arm.com> >
> Sent: Tuesday, June 26, 2018 6:09 PM
> To: Jim Schaad mailto:i...@augustcellars.com> >; 
> 'Benjamin Kaduk'
> mailto:ka...@mit.edu> >; 'Mike Jones' 
> mailto:michael.jo...@microsoft.com> >
> Cc: draft-ietf-ace-cwt-proof-of-possess...@ietf.org 
> <mailto:draft-ietf-ace-cwt-proof-of-possess...@ietf.org> ; ace@ietf.org 
> <mailto:ace@ietf.org> 
> Subject: RE: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-
> possession-02
> 
> Hi Jim,
> 
> you are essentially proposing that we should not directly use the key id
that
> is in the CWT-PoP but rather use it as input in a key derivation function.
The
> details of that key derivation function are specified outside the CWT-POP
> document and most likely in the context of the various profiles.
> Your proposals below suggest to use, among other things, the session key
as
> input to that function. That sounds pretty straight forward but raises the
> question why we fail to trust the implementer to create random key ids but
> then still trust them to create random keys.
> 
> That's fine for me nevertheless.
> 
> Ciao
> Hannes
> 
> -Original Message-
> From: Jim Schaad [mailto:i...@augustcellars.com 
> <mailto:i...@augustcellars.com> ]
> Sent: 24 June 2018 10:15
> To: 'Benjamin Kaduk'; 'Mike Jones'
> Cc: Hannes Tschofenig; draft-ietf-ace-cwt-proof-of-possess...@ietf.org 
> <mailto:draft-ietf-ace-cwt-proof-of-possess...@ietf.org> ;
> ace@ietf.org <mailto:ace@ietf.org> 
> Subject: RE: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-
> possession-02
> 
> Thinking things through, I would be more comfortable with something like
> the
> following:
> 
> 1.  Create a confirmation called 'computed key id'.  This has two basic
> values:  What is the computation method?  What is the proof value?  You
can
> optionally have an unprotected KID value used to filter the set of keys on
the
> RS down to a reasonable set to enumerate (hopefully one).
> 
> 2.  For RPK and TLS:  Define a method called hash of SPKI which has a hash
> method as a par

Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02

[Hannes Tschofenig]

Hi Jim,

It sounds like we need some high bandwidth face-to-face time on this issue in 
Montreal.
This is an interesting issue and IMHO reaches outside the CWT PoP document.

Ciao
Hannes

-Original Message-
From: Jim Schaad [mailto:i...@augustcellars.com]
Sent: 26 June 2018 18:57
To: Hannes Tschofenig; 'Benjamin Kaduk'; 'Mike Jones'
Cc: draft-ietf-ace-cwt-proof-of-possess...@ietf.org; ace@ietf.org
Subject: RE: [Ace] Key IDs ... RE: WGLC on 
draft-ietf-ace-cwt-proof-of-possession-02

Hannes,

My worry is not about implementers getting this correct and picking random
key ids.  My worry is about an attacker seeing the key id of somebody and
trying to use it either with the same or a different AS and getting a key
and then getting permissions associated with the initial key that they
should not be doing.

This is about an attack not about getting things to generally work right.

Jim


> -Original Message-
> From: Hannes Tschofenig 
> Sent: Tuesday, June 26, 2018 6:09 PM
> To: Jim Schaad ; 'Benjamin Kaduk'
> ; 'Mike Jones' 
> Cc: draft-ietf-ace-cwt-proof-of-possess...@ietf.org; ace@ietf.org
> Subject: RE: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-
> possession-02
>
> Hi Jim,
>
> you are essentially proposing that we should not directly use the key id
that
> is in the CWT-PoP but rather use it as input in a key derivation function.
The
> details of that key derivation function are specified outside the CWT-POP
> document and most likely in the context of the various profiles.
> Your proposals below suggest to use, among other things, the session key
as
> input to that function. That sounds pretty straight forward but raises the
> question why we fail to trust the implementer to create random key ids but
> then still trust them to create random keys.
>
> That's fine for me nevertheless.
>
> Ciao
> Hannes
>
> -Original Message-
> From: Jim Schaad [mailto:i...@augustcellars.com]
> Sent: 24 June 2018 10:15
> To: 'Benjamin Kaduk'; 'Mike Jones'
> Cc: Hannes Tschofenig; draft-ietf-ace-cwt-proof-of-possess...@ietf.org;
> ace@ietf.org
> Subject: RE: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-
> possession-02
>
> Thinking things through, I would be more comfortable with something like
> the
> following:
>
> 1.  Create a confirmation called 'computed key id'.  This has two basic
> values:  What is the computation method?  What is the proof value?  You
can
> optionally have an unprotected KID value used to filter the set of keys on
the
> RS down to a reasonable set to enumerate (hopefully one).
>
> 2.  For RPK and TLS:  Define a method called hash of SPKI which has a hash
> method as a parameter.  Given that this can be computed independently by
> all entities based on a Public Key value and it will be unique then you
have a
> key identifier that will not have collisions independent of who issues the
> CWT.
>
> 3.  For PSK and TLS:  Define a method which takes some parameters
including
> the key value, the CWT issuer identity and perhaps some random string and
> compute a proof of possession value on the PSK.
>
> 4.  For PSK and OSCORE: Define a similar method the question would be what
> the key value is to be used but that can be defined as part of OSCORE
>
> When using the keys for TLS
>
> For RPK the key is carried in the handshake and the server/client can
> generate the computed key id and compare it to what the AS distributed.
> The server can identify which CWTs are applicable by either comparison of
> the RPKs or the computed key id.  This means you have a high probability
> that you will not make a mistake and match to the wrong key.
>
> For PSK the identifier is carried in the handshake which is used to look
up a
> key value and the handshake is performed.  By matching computed key ids
> with the secret value one can ensure to a high probably that only CWTs
that
> reference the same secret are going to be used for permissions even if
they
> come from different AS entities.
>
> For OSCORE it is similar, the identifier is used to look up a key value
and by
> decrypting the CWT the key value is proofed.  You then match computed key
> ids in the same manner.
>
> If you really want to have something that is not cryptographically
computed
> and point to something else, then it makes more sense to me to reference a
> CWT issued by the same entity and say "use the same conformation method
> as this CWT does".
>
> jim
>
> > -Original Message-
> > From: Benjamin Kaduk 
> > Sent: Saturday, June 23, 2018 11:30 PM
> > To: Mike Jones 
> > Cc: Hannes Tschofenig ; Jim Schaad
> > ;
> > draft-ietf-

Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02

[Hannes Tschofenig]

Samuel, Jim,

We have two cases in ACE-OAuth:


1)  Client provides a key (or a reference to a key) to the AS. It wants the 
AS to include that key into the PoP token. The key is the long version of the 
key id*.

2)  Client asks the AS to get a token. In this case the AS creates a key 
and places that key or key id in the PoP token.

We seem to be worried that these keys / key ids are not unique over the 
lifetime of the tokens.
The ACE-OAuth document should say that the AS has to make sure that keys and 
key ids are not re-used over the lifetime of a PoP token, unless this is a 
desired behaviour.
I don’t think that the CWT PoP token is the right place to discuss this topic.

Ciao
Hannes

*: Here is what the draft says:

“
The proof-of-possession key can also be identified by the use of a
   Key ID instead of communicating the actual key, provided the
   recipient is able to obtain the identified key using the Key ID.
“

From: Samuel Erdtman [mailto:erdt...@spotify.com]
Sent: 27 June 2018 08:18
To: Jim Schaad
Cc: Hannes Tschofenig; Benjamin Kaduk; Mike Jones; 
draft-ietf-ace-cwt-proof-of-possess...@ietf.org; ace@ietf.org
Subject: Re: [Ace] Key IDs ... RE: WGLC on 
draft-ietf-ace-cwt-proof-of-possession-02

Jim, are you saying that if the client can pick the key identifier and if it 
has seen a key identifier of another client it could request a PoP token with 
the observed key-id and the observed subject but with an new key.
I guess this is a potential scenario that could be worth mentioning in security 
considerations.

If we look at ACE-OAuth there are as far as I can tell a few things that makes 
this a hard attack to do.

When the client makes the token request it is authenticated.

And with the subject being the authenticated client cannot control what goes 
into the cwt as subject

Since the cwt with the PoP key is signed there is no way for the attacking 
client to retro-fit the token to suit its needs e.g. change subject or key-id.

Finally I think it is preferable if the server selects key identifier.

Best regards
//Samuel


On Tue, 26 Jun 2018 at 18:57, Jim Schaad 
mailto:i...@augustcellars.com>> wrote:
Hannes,

My worry is not about implementers getting this correct and picking random
key ids.  My worry is about an attacker seeing the key id of somebody and
trying to use it either with the same or a different AS and getting a key
and then getting permissions associated with the initial key that they
should not be doing.

This is about an attack not about getting things to generally work right.

Jim


> -Original Message-
> From: Hannes Tschofenig 
> mailto:hannes.tschofe...@arm.com>>
> Sent: Tuesday, June 26, 2018 6:09 PM
> To: Jim Schaad mailto:i...@augustcellars.com>>; 
> 'Benjamin Kaduk'
> mailto:ka...@mit.edu>>; 'Mike Jones' 
> mailto:michael.jo...@microsoft.com>>
> Cc: 
> draft-ietf-ace-cwt-proof-of-possess...@ietf.org<mailto:draft-ietf-ace-cwt-proof-of-possess...@ietf.org>;
>  ace@ietf.org<mailto:ace@ietf.org>
> Subject: RE: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-
> possession-02
>
> Hi Jim,
>
> you are essentially proposing that we should not directly use the key id
that
> is in the CWT-PoP but rather use it as input in a key derivation function.
The
> details of that key derivation function are specified outside the CWT-POP
> document and most likely in the context of the various profiles.
> Your proposals below suggest to use, among other things, the session key
as
> input to that function. That sounds pretty straight forward but raises the
> question why we fail to trust the implementer to create random key ids but
> then still trust them to create random keys.
>
> That's fine for me nevertheless.
>
> Ciao
> Hannes
>
> -Original Message-
> From: Jim Schaad 
> [mailto:i...@augustcellars.com<mailto:i...@augustcellars.com>]
> Sent: 24 June 2018 10:15
> To: 'Benjamin Kaduk'; 'Mike Jones'
> Cc: Hannes Tschofenig; 
> draft-ietf-ace-cwt-proof-of-possess...@ietf.org<mailto:draft-ietf-ace-cwt-proof-of-possess...@ietf.org>;
> ace@ietf.org<mailto:ace@ietf.org>
> Subject: RE: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-
> possession-02
>
> Thinking things through, I would be more comfortable with something like
> the
> following:
>
> 1.  Create a confirmation called 'computed key id'.  This has two basic
> values:  What is the computation method?  What is the proof value?  You
can
> optionally have an unprotected KID value used to filter the set of keys on
the
> RS down to a reasonable set to enumerate (hopefully one).
>
> 2.  For RPK and TLS:  Define a method called hash of SPKI which has a hash
> method as a parameter.  Given that this can be computed independently b

Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02

[Jim Schaad]

I agree that some F2F on this would be useful.

> -Original Message-
> From: Hannes Tschofenig 
> Sent: Wednesday, June 27, 2018 9:32 AM
> To: Jim Schaad ; 'Benjamin Kaduk'
> ; 'Mike Jones' 
> Cc: draft-ietf-ace-cwt-proof-of-possess...@ietf.org; ace@ietf.org
> Subject: RE: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-
> possession-02
> 
> Hi Jim,
> 
> It sounds like we need some high bandwidth face-to-face time on this issue
> in Montreal.
> This is an interesting issue and IMHO reaches outside the CWT PoP
> document.
> 
> Ciao
> Hannes
> 
> -Original Message-
> From: Jim Schaad [mailto:i...@augustcellars.com]
> Sent: 26 June 2018 18:57
> To: Hannes Tschofenig; 'Benjamin Kaduk'; 'Mike Jones'
> Cc: draft-ietf-ace-cwt-proof-of-possess...@ietf.org; ace@ietf.org
> Subject: RE: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-
> possession-02
> 
> Hannes,
> 
> My worry is not about implementers getting this correct and picking random
> key ids.  My worry is about an attacker seeing the key id of somebody and
> trying to use it either with the same or a different AS and getting a key
and
> then getting permissions associated with the initial key that they should
not
> be doing.
> 
> This is about an attack not about getting things to generally work right.
> 
> Jim
> 
> 
> > -Original Message-
> > From: Hannes Tschofenig 
> > Sent: Tuesday, June 26, 2018 6:09 PM
> > To: Jim Schaad ; 'Benjamin Kaduk'
> > ; 'Mike Jones' 
> > Cc: draft-ietf-ace-cwt-proof-of-possess...@ietf.org; ace@ietf.org
> > Subject: RE: [Ace] Key IDs ... RE: WGLC on
> > draft-ietf-ace-cwt-proof-of-
> > possession-02
> >
> > Hi Jim,
> >
> > you are essentially proposing that we should not directly use the key
> > id
> that
> > is in the CWT-PoP but rather use it as input in a key derivation
function.
> The
> > details of that key derivation function are specified outside the
> > CWT-POP document and most likely in the context of the various profiles.
> > Your proposals below suggest to use, among other things, the session
> > key
> as
> > input to that function. That sounds pretty straight forward but raises
> > the question why we fail to trust the implementer to create random key
> > ids but then still trust them to create random keys.
> >
> > That's fine for me nevertheless.
> >
> > Ciao
> > Hannes
> >
> > -Original Message-
> > From: Jim Schaad [mailto:i...@augustcellars.com]
> > Sent: 24 June 2018 10:15
> > To: 'Benjamin Kaduk'; 'Mike Jones'
> > Cc: Hannes Tschofenig;
> > draft-ietf-ace-cwt-proof-of-possess...@ietf.org;
> > ace@ietf.org
> > Subject: RE: [Ace] Key IDs ... RE: WGLC on
> > draft-ietf-ace-cwt-proof-of-
> > possession-02
> >
> > Thinking things through, I would be more comfortable with something
> > like the
> > following:
> >
> > 1.  Create a confirmation called 'computed key id'.  This has two
> > basic
> > values:  What is the computation method?  What is the proof value?
> > You
> can
> > optionally have an unprotected KID value used to filter the set of
> > keys on
> the
> > RS down to a reasonable set to enumerate (hopefully one).
> >
> > 2.  For RPK and TLS:  Define a method called hash of SPKI which has a
> > hash method as a parameter.  Given that this can be computed
> > independently by all entities based on a Public Key value and it will
> > be unique then you
> have a
> > key identifier that will not have collisions independent of who issues
> > the CWT.
> >
> > 3.  For PSK and TLS:  Define a method which takes some parameters
> including
> > the key value, the CWT issuer identity and perhaps some random string
> > and compute a proof of possession value on the PSK.
> >
> > 4.  For PSK and OSCORE: Define a similar method the question would be
> > what the key value is to be used but that can be defined as part of
> > OSCORE
> >
> > When using the keys for TLS
> >
> > For RPK the key is carried in the handshake and the server/client can
> > generate the computed key id and compare it to what the AS distributed.
> > The server can identify which CWTs are applicable by either comparison
> > of the RPKs or the computed key id.  This means you have a high
> > probability that you will not make a mistake and match to the wrong key.
> >
> > For PSK the identifier is carried in the handshake which 

Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02

[Samuel Erdtman]

Thanks for the clarifying comments here comes a few replies since I will
not be able to join the IETF meeting :-(

see inline

On Wed, Jun 27, 2018 at 9:19 AM, Jim Schaad  wrote:

>
>
>
>
> *From:* Samuel Erdtman 
> *Sent:* Wednesday, June 27, 2018 8:18 AM
> *To:* Jim Schaad 
> *Cc:* Hannes Tschofenig ; Benjamin Kaduk <
> ka...@mit.edu>; Mike Jones ;
> draft-ietf-ace-cwt-proof-of-possess...@ietf.org; ace@ietf.org
> *Subject:* Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-
> possession-02
>
>
>
> Jim, are you saying that if the client can pick the key identifier and if
> it has seen a key identifier of another client it could request a PoP token
> with the observed key-id and the observed subject but with an new key.
> I guess this is a potential scenario that could be worth mentioning in
> security considerations.
>
> [JLS] No I am not assuming that the observed subject is also chosen by the
> attacker, just the observed key-id.
>
OK, see comments below on why I think the attacker would have to know the
subject too.


>
> If we look at ACE-OAuth there are as far as I can tell a few things that
> makes this a hard attack to do.
>
> When the client makes the token request it is authenticated.
>
> [JLS] Unclear why this is relevant.  I am asking for this new token as
> myself.
>
In my opinion authentication of the client will significantly lessen the
number of attackers since they need to have some initial access. i.e. no
absolute protection but one layer.


> And with the subject being the authenticated client cannot control what
> goes into the cwt as subject
>
> [JLS] You are making an assumption that a) the subject is actually going
> to be populated rather than be left empty and thus be anonymous and 2) that
> the resource server is going to make any enforcement based on the subject.
> I expect it to be done based on audience and scope only.
>
My assumption is that RS will uniquely identify the key with Issuer,
Subject and Key-ID. If subject is omitted for an anonymous token I assume
that the AS (Issuer) makes sure the key-id is unique during the lifetime of
the token. If issuer is left out I assume it is identified by the CWT
signing key or that the RS only accept tokens from one AS.
When the key is found and has been used to authenticate the user of the
token I too expect that the RS does the authorization based on audience and
scope.


>
> Since the cwt with the PoP key is signed there is no way for the attacking
> client to retro-fit the token to suit its needs e.g. change subject or
> key-id.
>
> [JLS] I am asking for a new token not trying to modify an existing token
> so this is not especially relevant.
>
Based on my previous statement you should not be able to impersonate the
observed key with a token issued for you.

>
> Finally I think it is preferable if the server selects key identifier.
>
> [JLS] I would agree, however if you have two AS that are operating in the
> same authorization range and are not tightly linked then this is not easy
> for doing an additional privilege token where the POP is identified by the
> KID.  This is even harder if an RS is going to allow two different AS from
> different scopes to be authoritative as they would never coordinate
> together.
>
In the case of RS accepting tokens from multiple ASs I think the RS must
use the issuer (in the CWT) to do key lookup.

>
>
> Best regards
> //Samuel
>
>
> On Tue, 26 Jun 2018 at 18:57, Jim Schaad  wrote:
>
> Hannes,
>
> My worry is not about implementers getting this correct and picking random
> key ids.  My worry is about an attacker seeing the key id of somebody and
> trying to use it either with the same or a different AS and getting a key
> and then getting permissions associated with the initial key that they
> should not be doing.
>
> This is about an attack not about getting things to generally work right.
>
> Jim
>
>
> > -----Original Message-
> > From: Hannes Tschofenig 
> > Sent: Tuesday, June 26, 2018 6:09 PM
> > To: Jim Schaad ; 'Benjamin Kaduk'
> > ; 'Mike Jones' 
> > Cc: draft-ietf-ace-cwt-proof-of-possess...@ietf.org; ace@ietf.org
> > Subject: RE: [Ace] Key IDs  RE: WGLC on draft-ietf-ace-cwt-proof-of-
> > possession-02
> >
> > Hi Jim,
> >
> > you are essentially proposing that we should not directly use the key id
> that
> > is in the CWT-PoP but rather use it as input in a key derivation
> function.
> The
> > details of that key derivation function are specified outside the CWT-POP
> > document and most likely in the context of the various profiles.
> > Your proposals below suggest to use, among other

Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02

[Jim Schaad]

 

 

From: Samuel Erdtman  
Sent: Thursday, June 28, 2018 5:40 PM
To: Jim Schaad 
Cc: Samuel Erdtman ; 
draft-ietf-ace-cwt-proof-of-possess...@ietf.org; Mike Jones 
; Hannes Tschofenig ; 
Benjamin Kaduk ; ace 
Subject: Re: [Ace] Key IDs ... RE: WGLC on 
draft-ietf-ace-cwt-proof-of-possession-02

 

Thanks for the clarifying comments here comes a few replies since I will not be 
able to join the IETF meeting :-(

 

see inline

 

On Wed, Jun 27, 2018 at 9:19 AM, Jim Schaad mailto:i...@augustcellars.com> > wrote:

 

 

From: Samuel Erdtman mailto:erdt...@spotify.com> > 
Sent: Wednesday, June 27, 2018 8:18 AM
To: Jim Schaad mailto:i...@augustcellars.com> >
Cc: Hannes Tschofenig mailto:hannes.tschofe...@arm.com> >; Benjamin Kaduk mailto:ka...@mit.edu> >; Mike Jones mailto:michael.jo...@microsoft.com> >; 
draft-ietf-ace-cwt-proof-of-possess...@ietf.org 
<mailto:draft-ietf-ace-cwt-proof-of-possess...@ietf.org> ; ace@ietf.org 
<mailto:ace@ietf.org> 
Subject: Re: [Ace] Key IDs ... RE: WGLC on 
draft-ietf-ace-cwt-proof-of-possession-02

 

Jim, are you saying that if the client can pick the key identifier and if it 
has seen a key identifier of another client it could request a PoP token with 
the observed key-id and the observed subject but with an new key. 
I guess this is a potential scenario that could be worth mentioning in security 
considerations.

[JLS] No I am not assuming that the observed subject is also chosen by the 
attacker, just the observed key-id.

OK, see comments below on why I think the attacker would have to know the 
subject too.

 


If we look at ACE-OAuth there are as far as I can tell a few things that makes 
this a hard attack to do.

When the client makes the token request it is authenticated.

[JLS] Unclear why this is relevant.  I am asking for this new token as myself.

In my opinion authentication of the client will significantly lessen the number 
of attackers since they need to have some initial access. i.e. no absolute 
protection but one layer.

 

[JLS] I am already in the system and have full credentials.  I am trying to get 
the same permissions that you have.  Not all attackers are external to the 
system.

 


And with the subject being the authenticated client cannot control what goes 
into the cwt as subject

[JLS] You are making an assumption that a) the subject is actually going to be 
populated rather than be left empty and thus be anonymous and 2) that the 
resource server is going to make any enforcement based on the subject.  I 
expect it to be done based on audience and scope only.

My assumption is that RS will uniquely identify the key with Issuer, Subject 
and Key-ID. If subject is omitted for an anonymous token I assume that the AS 
(Issuer) makes sure the key-id is unique during the lifetime of the token. If 
issuer is left out I assume it is identified by the CWT signing key or that the 
RS only accept tokens from one AS.

When the key is found and has been used to authenticate the user of the token I 
too expect that the RS does the authorization based on audience and scope.

 

[JLS] I am not sure how this is going to work.  As the CS I do a DTLS connect 
to the RS and put the Key-ID into the PSK identifier field.  The RS now has the 
Key-ID, but does not have the Issuer or Subject information.  Are you using 
this triple value binding someplace else?

 


Since the cwt with the PoP key is signed there is no way for the attacking 
client to retro-fit the token to suit its needs e.g. change subject or key-id.

[JLS] I am asking for a new token not trying to modify an existing token so 
this is not especially relevant.

Based on my previous statement you should not be able to impersonate the 
observed key with a token issued for you.

 

[JLS] Given two anonymous subject fields, the subject would not be a 
differentiator


Finally I think it is preferable if the server selects key identifier. 

[JLS] I would agree, however if you have two AS that are operating in the same 
authorization range and are not tightly linked then this is not easy for doing 
an additional privilege token where the POP is identified by the KID.  This is 
even harder if an RS is going to allow two different AS from different scopes 
to be authoritative as they would never coordinate together.

In the case of RS accepting tokens from multiple ASs I think the RS must use 
the issuer (in the CWT) to do key lookup.

 

[JLS] That may be true, however I have still not seen how to do the processing 
of getting a supplementary CWT and thus don’t know how it works.  I was 
assuming that the Client would send a KID as part of it’s request to the AS so 
one now has interesting questions of how the server does the assignment.  Also 
having a KID as part of an asymmetric key is probably going to be normal 
operating procedure so this is another case where the Client is providing one.

 

Jim

 



Best regards
//Samuel



On Tue, 26 Jun 2018 at

Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02

[Samuel Erdtman]

see inline

On Fri, Jun 29, 2018 at 7:57 AM, Jim Schaad  wrote:

>
>
>
>
> *From:* Samuel Erdtman 
> *Sent:* Thursday, June 28, 2018 5:40 PM
> *To:* Jim Schaad 
> *Cc:* Samuel Erdtman ; draft-ietf-ace-cwt-proof-of-
> possess...@ietf.org; Mike Jones ; Hannes
> Tschofenig ; Benjamin Kaduk ;
> ace 
> *Subject:* Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-
> possession-02
>
>
>
> Thanks for the clarifying comments here comes a few replies since I will
> not be able to join the IETF meeting :-(
>
>
>
> see inline
>
>
>
> On Wed, Jun 27, 2018 at 9:19 AM, Jim Schaad 
> wrote:
>
>
>
>
>
> *From:* Samuel Erdtman 
> *Sent:* Wednesday, June 27, 2018 8:18 AM
> *To:* Jim Schaad 
> *Cc:* Hannes Tschofenig ; Benjamin Kaduk <
> ka...@mit.edu>; Mike Jones ;
> draft-ietf-ace-cwt-proof-of-possess...@ietf.org; ace@ietf.org
> *Subject:* Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-
> possession-02
>
>
>
> Jim, are you saying that if the client can pick the key identifier and if
> it has seen a key identifier of another client it could request a PoP token
> with the observed key-id and the observed subject but with an new key.
> I guess this is a potential scenario that could be worth mentioning in
> security considerations.
>
> [JLS] No I am not assuming that the observed subject is also chosen by the
> attacker, just the observed key-id.
>
> OK, see comments below on why I think the attacker would have to know the
> subject too.
>
>
>
>
> If we look at ACE-OAuth there are as far as I can tell a few things that
> makes this a hard attack to do.
>
> When the client makes the token request it is authenticated.
>
> [JLS] Unclear why this is relevant.  I am asking for this new token as
> myself.
>
> In my opinion authentication of the client will significantly lessen the
> number of attackers since they need to have some initial access. i.e. no
> absolute protection but one layer.
>
>
>
> [JLS] I am already in the system and have full credentials.  I am trying
> to get the same permissions that you have.  Not all attackers are external
> to the system.
>

I agree, but the number of such attackers are fewer and you could revoke
access to such users. It is not perfect but it is better than nothing.


>
>
>
> And with the subject being the authenticated client cannot control what
> goes into the cwt as subject
>
> [JLS] You are making an assumption that a) the subject is actually going
> to be populated rather than be left empty and thus be anonymous and 2) that
> the resource server is going to make any enforcement based on the subject..
> I expect it to be done based on audience and scope only.
>
> My assumption is that RS will uniquely identify the key with Issuer,
> Subject and Key-ID. If subject is omitted for an anonymous token I assume
> that the AS (Issuer) makes sure the key-id is unique during the lifetime of
> the token. If issuer is left out I assume it is identified by the CWT
> signing key or that the RS only accept tokens from one AS.
>
> When the key is found and has been used to authenticate the user of the
> token I too expect that the RS does the authorization based on audience and
> scope.
>
>
>
> [JLS] I am not sure how this is going to work.  As the CS I do a DTLS
> connect to the RS and put the Key-ID into the PSK identifier field.  The RS
> now has the Key-ID, but does not have the Issuer or Subject information.
> Are you using this triple value binding someplace else?
>

I would not send the key-id in the PSK identifier I would send the full
token as described in draft-ietf-ace-dtls-authorize (4.1. DTLS Channel
Setup Between C and RS).


>
>
>
> Since the cwt with the PoP key is signed there is no way for the attacking
> client to retro-fit the token to suit its needs e.g. change subject or
> key-id.
>
> [JLS] I am asking for a new token not trying to modify an existing token
> so this is not especially relevant.
>
> Based on my previous statement you should not be able to impersonate the
> observed key with a token issued for you.
>
>
>
> [JLS] Given two anonymous subject fields, the subject would not be a
> differentiator
>

I agree so the AS (issuer) MUST keep key-id unique for the lifetime of the
token.

>
> Finally I think it is preferable if the server selects key identifier.
>
> [JLS] I would agree, however if you have two AS that are operating in the
> same authorization range and are not tightly linked then this is not easy
> for doing an additional privilege token where the POP is identified by the
> KID.  This is even harder if an RS is going to allow two different AS from
&

Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02

[Ludwig Seitz]

I've finally had the time to think about that Key ID issue for ACE.

Here is what I got:


The case Jim is worried about is the following:

* Client A has key K1 with KID = "A"
* RS also has key K1 with KID = "A"
* Client A has the right to token T1 on RS
* Client B has the right to token T2 on RS


1. Client A gets T1 from AS bound via the cnf claim to KID="A"

2. Client A transfers T1 to RS

3. Client A performs the proof-of-possession with key K1 and gets access 
to RS according to T1


4. Malicious Client B learns of the KID = "A" for T1 (but not of K1).

5. Client B chooses K2 and assigns it KID = "A"

6. Client B gets 2 from AS bound via the cnf claim to KID="A"

7. Client B transfers T2 to RS

8. ?

9. Client B performs the proof-of-possession for K2 and gets access to 
both T1 and T2



Now I'm claiming there is no step 8 that makes step 9 work, unless B can 
get RS to accept a new key (K2) with a duplicate KID.


Thus I'd say, we need to Security Considerations about handling key Ids 
at the recipient of a CWT containing a cnf claim. Something along the 
lines of:


"If a recipient receives a CWT with the a confirmation claim, the 
recipient MUST make sure that keys that may be contained in that claim 
do not have a key identifier that duplicates one of a different key that 
the recipient already recognizes."


Or shorter:

"Recipients MUST make sure that they do not accept identical key 
identifiers for different keys"


/Ludwig

--
Ludwig Seitz, PhD
Security Lab, RISE SICS
Phone +46(0)70-349 92 51

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02

[Ludwig Seitz]

On 2018-07-03 11:31, Ludwig Seitz wrote:



6. Client B gets 2 from AS bound via the cnf claim to KID="A"


This should of course read:

Client B gets T2 from AS ...


/Ludwig

--
Ludwig Seitz, PhD
Security Lab, RISE SICS
Phone +46(0)70-349 92 51

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02

[Mike Jones]

Thanks, Ludwig.  Note that last paragraph of the new Operational Considerations 
section at 
https://tools.ietf.org/html/draft-ietf-ace-cwt-proof-of-possession-03#section-6 
addresses this issue.  In particular, the last sentence of the section talks 
about the need to keep keys used in different contexts separate if there is 
otherwise any chance of confusion.

I'll also note that for the constrained environments that ACE is addressing, I 
expect that deployments with exactly one PoP key to be predominant use case.  
In this use case, such confusion is impossible in the first place.

-- Mike

-Original Message-
From: Ace  On Behalf Of Ludwig Seitz
Sent: Tuesday, July 3, 2018 2:33 AM
To: 'ace' 
Subject: Re: [Ace] Key IDs ... RE: WGLC on 
draft-ietf-ace-cwt-proof-of-possession-02

On 2018-07-03 11:31, Ludwig Seitz wrote:

> 
> 6. Client B gets 2 from AS bound via the cnf claim to KID="A"
> 
This should of course read:

Client B gets T2 from AS ...


/Ludwig

-- 
Ludwig Seitz, PhD
Security Lab, RISE SICS
Phone +46(0)70-349 92 51

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace