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

[Hannes Tschofenig <[e-mail]>]

Hi Michael,

thanks for the feedback.

One minor remark on the Kerberos cross-realm authentication.

My understanding of the challenge with deployments (from discussions
with the Kerberos folks) is that there have to be business reasons for
deploying cross-realm authentication. These business reasons are not
always there and they require a considerable amount of effort since
business agreements (including legal aspects) do not necessarily scale
in the same way as technology could do.

This is also a painful lesson the original OpenID guys learned (which is
why it is dead now). They approached the problem of federations in a
technical way and failed to understand that federations are 95%
business/legal constructs and only 5% technology.

Ciao
Hannes


On 07/09/2014 04:09 PM, Michael Richardson wrote:
> 
> 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. 
> 
> 
> 
> _______________________________________________
> Ace mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ace
>