Re: [Ace] Questions for the IETF#90 Meeting

[Michael Richardson <[e-mail]>]

Hannes Tschofenig <[e-mail]> wrote:
    > 1) Are there requirements/use cases that allow anything other than the
    > OAuth/Kerberos design pattern?

I think that there are two questions here:
  1) is the OAuth/Kerberos design pattern sufficient? (does it do everything)
  2) is the OAUTH/Kerberos design pattern necessary?  (can we throw something away?)

My instinct is that it handles all of the operational parts, but it does not
handle any of the enrollment parts, particularly for the case where the
parties are offline.   You will recall that you felt at the BOF that the
enrollment case was out of scope.

    > 2) Should the design re-use existing work or should the design start
    > from scratch?

    > This is more a question of taste / preference but will obviously have a
    > huge impact on the subsequent work in the group.

I think that it worth spending some time to think about a CBOR encoding of
OAuth2, which I think makes use of JSON.  I don't think we have any mapping
of Kerberos into JSON, but I could be wrong.  The idea is to start with a
baseline situation and then decided if we should innovate.

    > 3) Should the design be based on symmetric or asymmetric crypto?
    > (or both?)

    > We have various documents that talk about this issue, for example
    > draft-seitz-ace-design-considerations-00 and
    > draft-seitz-ace-problem-description-01

After enrollment, symmetric crypto is sufficient.

    > 4) How to address cross-domain support in the initial protocol design?
    > Is it a feature that can be added later easily?

    > draft-gerdes-ace-actors-01 talks about this aspect.

It must be present from day one.  That is one thing which dis-recommends a
pure Kerberos pattern, or at least observes Kerberos to include all the pkinit and 
cross-realm stuff from the beginning.  My limited experience with kerberos is
that there must be significant operational hurdles to doing cross-realm
things, or it would occur far more often.

    > PS: One question that has been answered by all document in the same way
    > at the moment is about the use of DTLS. Currently, everyone seems to be
    > focused on using DTLS everywhere. There would be alternative approaches
    > as well.

I don't prefer to have any alternative approaches be considered. 

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [