Re: [Ace] Alexey Melnikov's Discuss on draft-ietf-ace-coap-est-17: (with DISCUSS and COMMENT)

[Carsten Bormann]

On Dec 20, 2019, at 01:47, Benjamin Kaduk  wrote:
> 
>> The statement above
>> 
>>  When omitted, they are logically
>>  assumed to be the transport protocol destination address and port
>>  respectively.  Explicit Uri-Host and Uri-Port Options are
>>  typically used when an endpoint hosts multiple virtual servers and
>>  uses the Options to route the requests accordingly.
>> 
>> and the last quoted statement: How can the sender know whether or not it is 
>> Ok
>> to omit Uri-Host/Uri-Port?
> 
> How do you know when you need to send SNI to a TLS server?  "If you try
> without and get a strange certificate back."  I think that a similar
> situation is possible here, though of course you may just know from
> out-of-band configuration.

RFC 7252 says:

   The default value of the Uri-Host Option is the IP literal
   representing the destination IP address of the request message.
   Likewise, the default value of the Uri-Port Option is the destination
   UDP port.  The default values for the Uri-Host and Uri-Port Options
   are sufficient for requests to most servers.  Explicit Uri-Host and
   Uri-Port Options are typically used when an endpoint hosts multiple
   virtual servers.

So there is a clear rule: If the URI has the IP address and port number 
(possibly defaulted), respectively, the options can be omitted.  This means you 
can almost always omit Uri-Port, and can omit Uri-Host if the URI had an IP 
address literal.  The latter is not unlikely if that URI came from a resource 
directory.  If the URI had a DNS name and you omit Uri-Host anyway, you are 
gambling that the server offers the same resource under the IP address the DNS 
name resolves to.  Not unlikely either, but still gambling, unless you have 
out-of-band information.  Now you might have verified the identity of the 
server already using a security protocol, in which case you could have more 
reason to believe you are addressing the right resource.

Grüße, Carsten

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

Re: [Ace] Magnus Westerlund's Discuss on draft-ietf-ace-coap-est-17: (with DISCUSS)

[Panos Kampanakis (pkampana)]

Thanks Magnus. 

> The EST-coaps client MUST support
> Block1 only if it sends EST-coaps requests with an IP packet size
> that exceeds the Path MTU.
> 
> I think the requirement for when Block1 is required to be supported in the
> above sentence is unclear. Is the intention to say: An EST-coaps MUST support
> block1 to be capable to send requests that would otherwise result in the
> reliance on IP level fragmentation?

Yes, that was the intention. We will rephrase it to say

   [...] The EST-coaps client MUST support
   Block1 only if it sends large EST-coaps requests that would 
   otherwise result to IP layer fragmentation.

Rgs,
Panos


-Original Message-
From: Ace  On Behalf Of Magnus Westerlund via Datatracker
Sent: Thursday, December 19, 2019 7:54 AM
To: The IESG 
Cc: draft-ietf-ace-coap-...@ietf.org; i...@augustcellars.com; 
ace-cha...@ietf.org; ace@ietf.org
Subject: [Ace] Magnus Westerlund's Discuss on draft-ietf-ace-coap-est-17: (with 
DISCUSS)

Magnus Westerlund has entered the following ballot position for
draft-ietf-ace-coap-est-17: Discuss

When responding, please keep the subject line intact and reply to all email 
addresses included in the To and CC lines. (Feel free to cut this introductory 
paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ace-coap-est/



--
DISCUSS:
--

Section 5.6:

The EST-coaps client MUST support
   Block1 only if it sends EST-coaps requests with an IP packet size
   that exceeds the Path MTU.

I think the requirement for when Block1 is required to be supported in the 
above sentence is unclear. Is the intention to say: An EST-coaps MUST support
block1 to be capable to send requests that would otherwise result in the 
reliance on IP level fragmentation?




___
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

Re: [Ace] Alissa Cooper's No Objection on draft-ietf-ace-coap-est-17: (with COMMENT)

[Panos Kampanakis (pkampana)]

Hi Alissa, 

Thank you for the feedback. 

> "It is also RECOMMENDED that the Implicit Trust Anchor database used
> for EST server authentication is carefully managed to reduce the
> chance of a third-party CA with poor certification practices
> jeopardizing authentication."
> 
> This strikes me as a slightly odd use of normative language (what are the 
> exception cases when the trust anchor database should not be carefully 
> managed?).
> 

The blurb is directly from RFC7030. We reiterate it here to point it out as a 
best practice and then we present a potential deviation from it for constrained 
environments. 

To avoid this confusion we can rephrase it as 

As discussed in Section 6 of [RFC7030], it is 
   "RECOMMENDED that the Implicit Trust Anchor database used
   for EST server authentication is carefully managed to reduce the
   chance of a third-party CA with poor certification practices
   jeopardizing authentication.  Disabling the Implicit Trust Anchor
   database after successfully receiving the Distribution of CA
   certificates response (Section 4.1.3 of [RFC7030]) limits any risk to
   the first DTLS exchange." [...]

Rgs, 
Panos


-Original Message-
From: Ace  On Behalf Of Alissa Cooper via Datatracker
Sent: Tuesday, December 17, 2019 2:35 PM
To: The IESG 
Cc: draft-ietf-ace-coap-...@ietf.org; i...@augustcellars.com; 
ace-cha...@ietf.org; ace@ietf.org
Subject: [Ace] Alissa Cooper's No Objection on draft-ietf-ace-coap-est-17: 
(with COMMENT)

Alissa Cooper has entered the following ballot position for
draft-ietf-ace-coap-est-17: No Objection

When responding, please keep the subject line intact and reply to all email 
addresses included in the To and CC lines. (Feel free to cut this introductory 
paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ace-coap-est/



--
COMMENT:
--

Section 10.1:

"It is also RECOMMENDED that the Implicit Trust Anchor database used
   for EST server authentication is carefully managed to reduce the
   chance of a third-party CA with poor certification practices
   jeopardizing authentication."

This strikes me as a slightly odd use of normative language (what are the 
exception cases when the trust anchor database should not be carefully 
managed?).


___
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

Re: [Ace] Alexey Melnikov's Discuss on draft-ietf-ace-coap-est-17: (with DISCUSS and COMMENT)

[Benjamin Kaduk]

On Wed, Dec 18, 2019 at 05:27:06AM -0800, Alexey Melnikov via Datatracker wrote:
> Alexey Melnikov has entered the following ballot position for
> draft-ietf-ace-coap-est-17: Discuss
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-ace-coap-est/
> 
> 
> 
> --
> DISCUSS:
> --
> 
> Thank you for this well written document. I have a couple of small DISCUSS
> points and a few minor comments/questions that I would like to discuss.
> 
> DISCUSS:
> 
> 5.4.  Message Bindings
> 
>o  The CoAP Options used are Uri-Host, Uri-Path, Uri-Port, Content-
>   Format, Block1, Block2, and Accept.  These CoAP Options are used
>   to communicate the HTTP fields specified in the EST REST messages.
>   The Uri-host and Uri-Port Options can be omitted from the COAP
>   message sent on the wire.
> 
> The statement above
> 
>   When omitted, they are logically
>   assumed to be the transport protocol destination address and port
>   respectively.  Explicit Uri-Host and Uri-Port Options are
>   typically used when an endpoint hosts multiple virtual servers and
>   uses the Options to route the requests accordingly.
> 
> and the last quoted statement: How can the sender know whether or not it is Ok
> to omit Uri-Host/Uri-Port?

How do you know when you need to send SNI to a TLS server?  "If you try
without and get a strange certificate back."  I think that a similar
situation is possible here, though of course you may just know from
out-of-band configuration.

> 7.  Parameters
> 
>It is recommended, based on experiments,
>to follow the default CoAP configuration parameters ([RFC7252]).
>However, depending on the implementation scenario, retransmissions
>and timeouts can also occur on other networking layers, governed by
>other configuration parameters.  When a change in a server parameter
>has taken place, the parameter values in the communicating endpoints
>MUST be adjusted as necessary.
> 
> The last sentence: use of MUST with passive voice is really unhelpful here.
> Adjusted by whom? How can this MUST be satisfied?
> 
> 
> --
> COMMENT:
> --
> 
> Comment:
> 
> 5.1.  Discovery and URIs
> 
>Clients and servers MUST support the short resource EST-coaps URIs.
> 
> Just to clarify: the original EST URIs are prohibited in COAP-EST?

My understanding is that the servers also have to support the original
(long) EST paths.

-Ben

> In 5.8:
> 
>In the case where the asymmetric encryption key is suitable for
>transport key operations the generated private key is encrypted with
>a symmetric key which is encrypted by the client-defined (in the CSR)
> 
> I would break up this sentence into 2 to make it clearer, as I initially read
> this as 2 encryption operations applying to the generated private key itself.
> So I suggest something like:
> 
>  In the case where the asymmetric encryption key is suitable for
>  transport key operations the generated private key is encrypted with
>  a symmetric key. The symmetric key itself is encrypted by the client-defined
>  (in the CSR)
> 
>asymmetric public key and is carried in an encryptedKey attribute in
>a KeyTransRecipientInfo structure.
> 
>Finally, if the asymmetric
>encryption key is suitable for key agreement, the generated private
>key is encrypted with a symmetric key which is encrypted by the
>client defined (in the CSR) asymmetric public key and is carried in
>an recipientEncryptedKeys attribute in a KeyAgreeRecipientInfo.
> 
> As above.
> 
> 

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

Re: [Ace] Review for draft-palombini-ace-coap-pubsub-profile

[Benjamin Kaduk]

On Wed, Dec 18, 2019 at 03:47:04PM +, Cigdem Sengul wrote:
> Dear Francesca,
> 
> Thank you for your responses to my comments.
> My comments are inline.
> 
> >
> >
> > In the following, I list a few things reading the draft made me think,
> > especially in its applicability to MQTT:
> >
> > (1) What is planned to make this document a generic pubsub solution? Will
> > there a generic architecture section, and specific descriptions for each of
> > the protocols?
> >
> >
> >
> > FP: Yes, I am planning to make some updates to the text to make this
> > generic. In general, I think the structure of the draft will be the same,
> > but each section would either have a sentence or (if longer text is needed)
> > a subsection talking about the different alternatives. For example, Section
> > 2 would remove current specific text about CoAP pubsub (only talk about
> > general pubsub) and would replace that text with an additional paragraph
> > mentioning that the pubsub protocol can be CoAP or MQTT. Section 3 would
> > have 2 subsections, coap_pubsub_app and mqtt_pubsub_app, etc.
> >
> >
> >
> 
> CS: YEs, sounds good.
> 
> 
> > For instance, if an MQTT client implements this,  the client would talk to
> > AS1 to get a token based on the way we describe in the mqtt-tls profile,
> > and then get keying material for topics from AS2.
> >
> > I expect the MQTT client would use a different profile name like
> > mqtt_tls_app to signal to AS1 that it is supporting the application layer
> > security. This is because the draft hints that there should be a policy
> > agreement between AS1 and AS2: “Note that AS1 and AS2 might either be
> > co-resident or be 2 separate physical entities, in which case access
> > control policies must be exchanged between AS1 and AS2, so that they agree
> > on rights fo  joining nodes about specific topics.”
> >
> >
> >
> > FP: That is all correct. Moreover, we can also discuss details such as
> > what communication protocol the Client uses to talk to AS2. Right now
> > ace-key-groupcomm is only defined for CoAP, but if MQTT prefers to use
> > HTTP, that is very easy to define.
> >
> >
> >
> >
> > (2) If we keep AS1 as the mqtt-tls profile AS, then for consistency sake,
> > the MQTT client would expect to talk to HTTPS to AS2, but the coap-pubsub
> > draft describes these, expectedly, in CoAP. Will there be support for HTTPS?
> >
> >
> >
> > FP: I promise I did not read this question before answering the text above
> > :) Yes. This is really easy to specify, we already do this with CBOR/JSON,
> > in ace-key-groupcomm:
> >
> >
> >
> > The ACE framework is based
> >
> >on CBOR [RFC7049], so CBOR is the format used in this specification.
> >
> >However, using JSON [RFC8259] instead of CBOR is possible, using the
> >
> >conversion method specified in Sections 4.1 and 4.2 of [RFC7049].
> >
> >
> >
> > We would add CoAP/HTTP in the same way ("CoAP is default, but HTTP works
> > the same way"). Then the pubsub-profile could specify which protocol is
> > used in the different profiles.
> >
> 
> CS: Cool. Because, I imagine a client or its AS would follow the same
> protocol, HTTPS,  to talk to the ASes, and then talk to MQTT to RS.
> 
> 
> > (3) In the mqtt_tls profile, the AS grants tokens that identify both
> > “publish” and “subscribe” rights and the topics by adding scopes in the
> > format, e.g. “publish_topic1” “subscribe_topic2/#”..  This format allows
> > representing all publish/subscribe permissions concisely for the client
> > which may be acting both as a publisher and a subscriber.
> >
> > In the coap-pubsub, this is separated between AS1 and AS2. “AS1 hosts the
> > policies about the Broker: what endpoints are allowed to Publish on the
> > Broker.” “The AS2 hosts the policies about the topic: what endpoints are
> > allowed to access what topic. “
> >
> > The coap-pubsub also permits that AS1 can host policies about what
> > endpoints are allowed to Subscribe to the Broker.
> >
> >
> >
> > However, wouldn’t this separation between AS1 and AS2 have the following
> > issue: Publisher P, having the permission to publish to topic1 and hence,
> > successfully getting an access token from AS1, then goes ahead and sends a
> > PUBLISH on topic 2, which it doesn’t have a right to publish.
> >
> > Wouldn't the broker would pass this message to subscribers, and the
> > subscribers would discard the message because the publisher does not belong
> > to their “publishers list” (subscribers have all the public keys of all
> > publishers). Have I missed something, does the draft protect against this
> > at the broker?
> >
> >
> >
> > FP: No, the broker would not accept this message. In fact, during the ACE
> > exchange between Publisher, AS1, and Broker, the Publisher would post a
> > token to the Broker that contains the resource it is allowed to publish to,
> > namely in this case topic 1. If it does have rights to publish to topic 2
> > as well, that would be included in the token. That is 

Re: [Ace] [Gen-art] Genart last call review of draft-ietf-ace-oauth-params-06

[elwynd]

Hi, Ludwig.Thanks for the prompt response.Regarding he major issue, I 
understand what the intention of the split was, but as far as early 
implementations are concerned, there is no such thing as a 'minimal breakage'; 
unless there is some cunning mechanism in the basic ace-oauth-authz protocol, 
changes to the structure of the items defined here will break the protocol.  
One possibility that I could see is the addition of extra keys in the COSE_Key 
dictionary structure: In this case you could add some extra words (in the 
ace-oauth-authz document) to indicate that unrecognized keys should be ignored. 
 This is associated with the editorial comments I made about s3.1 that would 
allow any other keys to be present in the COSE_Key object structure.  
Similarly, the obects defined here are effectively JSON/CBOR dictionaries.  The 
changes could be accomodated by adding comments in ace-oauth that extra keys in 
the items defined would be ignored.  In my opinion, it would be best to remove 
the comments about possible changes and just state that they have been 
separated out because they might be used in other contexts.  The possible 
'changes to the definitions' issue is just a matter of 'institutional memory'.  
If there is some mechanism, such as I mentioned above, to accommodate changes 
without neeeding an update to the ace-oauth-authz (or other protocols using 
these items), this should be explained.Regarding the h vs b64 representations, 
since they are only examples (and the strings are essentially arbitrary as the 
actual keys aren't in the document), I'd be inclined to put in h 
representations to avoid my question arisng.   Otherwise I think we are 
done.Cheers and best wishes for the Festive Season,ElwynSent from Samsung 
tablet.
 Original message From: Ludwig Seitz  
Date: 17/12/2019  16:53  (GMT+00:00) To: elw...@dial.pipex.com Cc: 
last-c...@ietf.org, gen-...@ietf.org, ace@ietf.org Subject: Re: [Gen-art] [Ace] 
Genart last call review of
  draft-ietf-ace-oauth-params-06 Hello Elwyn,thank you for your review. 
Comments inline./LudwigOn 2019-12-14 23:46, Elwyn Davies via Datatracker 
wrote:> Reviewer: Elwyn Davies> Review result: Not Ready>> I am the assigned 
Gen-ART reviewer for this draft. The General Area> Review Team (Gen-ART) 
reviews all IETF documents being processed> by the IESG for the IETF Chair.  
Please treat these comments just> like any other last call comments.>> For more 
information, please see the FAQ at>> 
.>> Document: 
draft-ietf-ace-oauth-params-06> Reviewer: Elwyn Davies> Review Date: 
2019-12-14> IETF LC End Date: 2019-12-13> IESG Telechat date: Not scheduled for 
a telechat>> I am the assigned Gen-ART reviewer for this draft. The General 
Area> Review Team (Gen-ART) reviews all IETF documents being processed> by the 
IESG for the IETF Chair.  Please treat these comments just> like any other last 
call comments.>> For more information, please see the FAQ at>> 
<">https://trac.ietf.org/trac/gen/wiki/GenArtfaq>;.>> Document: 
draft-ietf-ace-oauth-params-06> Reviewer: Elwyn Davies> Review Date: 
2019/12/14> IETF LC End Date: 2019/2/13> IESG Telechat date: (if known) N/A>> 
Summary: Not ready.  In particular there seems to be some doubt as to whether> 
the definitions in this document are actually stable - or alternatively that 
it> lacks a versioning mechanism to cope with changes that the might be.>> 
Major issues:> Dealing with possible updates to items defined here:> In s1 the 
following appears:>>  These parameters and claims can also be used in other 
contexts, and may>  need to be updated to align them with ongoing OAuth 
work. Therefore, these>  parameters and claims have been put into a 
dedicated document, to>  facilitate their use and any potential updates in 
a manner independent of>  [I-D.ietf-ace-oauth-authz].>> I am unclear 
whether this implies that it is intended that these potential> updates would 
alter the definitions here after they have been standardized or> alternatively 
that the standardization of this document should be delayed until> the 
alternative usage is defined.  If the first case applies, I do not see any> 
versioning mechanism that would allow early implementations to cope with later> 
updates of the items defined here.  In the second case, I have to ask myself> 
why this document has been submitted for standardization before the usages 
have> stabilized.>The intention with this document was to place certain 
parameters(req_cnf, cnf, rs_cnf) needed for draft-ietf-ace-oauth-authz into 
aseparate document, that could be updated or obsoleted by other draftswithout 
obsoleting or updating draft-ietf-ace-oauth-authz.This is mainly due to some 
work in the OAuth WG which has been runningin parallel, 
especiallyhttps://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution.Since
 this is not a high priority item for OAuth (the draft named abovehas expired), 
the 

[Ace] Magnus Westerlund's Discuss on draft-ietf-ace-coap-est-17: (with DISCUSS)

[Magnus Westerlund via Datatracker]

Magnus Westerlund has entered the following ballot position for
draft-ietf-ace-coap-est-17: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ace-coap-est/



--
DISCUSS:
--

Section 5.6:

The EST-coaps client MUST support
   Block1 only if it sends EST-coaps requests with an IP packet size
   that exceeds the Path MTU.

I think the requirement for when Block1 is required to be supported in the
above sentence is unclear. Is the intention to say: An EST-coaps MUST support
block1 to be capable to send requests that would otherwise result in the
reliance on IP level fragmentation?




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