Re: [sipcore] I-D Action: draft-ietf-sipcore-sip-token-authnz-01.txt

[Rifaat Shekh-Yusef <[e-mail]>]

On Tue, Jun 25, 2019 at 5:01 PM Paul Kyzivat <[e-mail]> wrote:

> Inline...
>
> On 6/25/19 1:32 PM, Rifaat Shekh-Yusef wrote:
> >
> >
> > On Tue, Jun 25, 2019 at 10:47 AM Paul Kyzivat <[e-mail]
> > <mailto:[e-mail]>> wrote:
> >
> >     On 6/25/19 9:05 AM, Rifaat Shekh-Yusef wrote:
> >      > Thanks Paul!
> >      >
> >      > Please, see my replies inline.
> >      >
> >      > Regards,
> >      >   Rifaat
> >      >
> >      >
> >      > On Mon, Jun 24, 2019 at 4:37 PM Paul Kyzivat
> >     <[e-mail] <mailto:[e-mail]>
> >      > <mailto:[e-mail] <mailto:[e-mail]>>>
> wrote:
> >      >
> >      >     On 6/24/19 12:58 PM, Rifaat Shekh-Yusef wrote:
> >      >      > All,
> >      >      >
> >      >      > We have submitted a new version of the draft that adds more
> >      >     details and
> >      >      > we believe address the comments provided so far.
> >      >      > Please, take a look and let us know what you think.
> >      >
> >      >     I think this still has things a bit backwards. Step [07] in
> >     2.1.2 seems
> >      >     out of place. Why would the UA know to prompt the user at
> >     this point,
> >      >     and if it did, how would the user know *which* credentials to
> >     provide.
> >      >
> >      > Yeah, this was a copy and paste from the previous flow.
> >      > I agree that the prompt should happen after the 401 response. I
> >     will fix
> >      > that.
> >
> >     Thx
> >
> >      >     With Digest, you would never prompt for credentials until you
> >     have
> >      >     received a 401 with WWW-Authenticate. The Realm in that is
> then
> >      >     displayed to the user as indication of which credentials he
> >     should
> >      >     supply.
> >      >
> >      >     I would expect something similar with Bearer. Presumably this
> >     will tell
> >      >     me "Google", or "Facebook", or whatever. In your case these
> >     may be
> >      >     alternatives that the user can choose among. So I think you
> >     need more
> >      >     explanation about how the alternatives are presented. Don't
> >     just pass
> >      >     the buck to 3261 on the WWW-Authenticate parameters. You have
> >     ones that
> >      >     aren't mentioned there, and the usage is probably somewhat
> >     different.
> >      >
> >      >
> >      > The UA gets redirected to an *Authorization Server (AS)*, which
> >     could in
> >      > theory redirect the UA to an *IdP *server to authenticate the
> user.
> >      > But, this is completely out of scope for this document, as this
> >     follows
> >      > a well-defined HTTP-based OAuth mechanism.
> >
> >     OK, as long as it somehow takes account of the server that requires
> >     authentication and the type(s) of authentication it is willing to
> >     accept. You can't rely on the UAC being psychic about what
> credentials
> >     are required.
> >
> >
> > Notice that the challenge provided in the WWW-Authenticate response,
> > defined in section 3, includes many details that could be used by the
> > UAC to prompt the user for the right credentials.
> > Is there anything missing that should be added to help the UAC?
>
> Yes, there is quite a bit, and scant information about what the
> significance is of each bit of it. IMO some explanation is needed of
> these items and how they are expected to be used.


Sure



> And a more fleshed out
> example that shows who puts up the UI to gather the needed info, what is
> included in the prompt, what comes back, and what is done with it then.
> Enough to relate it to real world experience.
>
> (AFAIK most real world experience is with web interfaces. For instance
> when hitting restricted web sites that require a login from Google,
> Facebook, Discus, etc. IIUC this could be much like that, including the
> choice of which of those to use. So a use case like that would be great.
>
>
I think UI related issues and authentication using 3rd party IdPs are
really out of scope of this document.




> >      >     After this has been done once, the UA can then cache the
> >     credentials
> >      >     for
> >      >     while and preemptively supply them in future registration
> >     requests.
> >      >     With
> >      >     Digest there are some guidelines on when to preemptively try
> >     them and
> >      >     when not. I would expect something similar for Bearer. There
> are
> >      >     probably some security reasons not to preemptively send the
> >     credentials
> >      >     to every server the UA attempts to connect to. As long as
> >     credentials
> >      >     are only being used for REGISTER this probably isn't a
> >     problem. But it
> >      >     certainly is possible for server to request credentials for
> >     requests
> >      >     other than REGISTER. I'd like to see a discussion of that too.
> >      >
> >      >
> >      > The UA never sends any credentials to the registrar, only to the
> >     AS/IdP.
> >      > The UA will only send the *Access Token *to the registrar which
> >     will be
> >      > able to validate that the token was issued by a trusted AS.
> >
> >     That is details. What the UA provides to the registrar are
> credentials
> >     in a functional sense, even if they are passed in an indirect way.
> >
> >
> > Fair enough
> >
> >     It still requires a security analysis, though the conclusions might
> be
> >     somewhat different. I *guess* that it is still a bad idea to hand out
> >     the access token indiscriminately to everyone you connect to.
> >
> > Yeah, this will be covered by the security consideration section.
> > In general, the UAC must always make sure that it is communicating with
> > the right registrar using TLS and proper validation of the server
> > certificate and the identity in that certificate.
>
> Again, while it is probably true that SIP authentication is mostly used
> with registrars, it is also possible for other servers to require
> authentication, for SUBSCRIBE, NOTIFY, or even INVITE. Any server can
> send a challenge. So the UA needs to be prepared for this and do the
> right thing.
>
> Doing that right includes caching credentials and providing them
> appropriately to avoid unnecessarily prompting the user too often. And
> then preemptively sending credentials becomes an optimization to avoid
> extra round trips. This of course is very important for REGISTER since
> it at times is used very frequently as a keep-alive. But at the same
> time one needs to have some security guidance on when it is appropriate
> to send preemptively and when not.
>
>
I will add text around this to indicate that non-REGISTER requests should
always include the Access Token in the request.


One answer might be that you should only preemptively send this stuff
> when you have previously (and recently?) been challenged by the "same"
> server, and then send only the credentials that resulted from that
> challenge. But even then there is a question of what "same" means. So
> this needs some explanatory text. The writeup for Digest give some of
> this, though it could probably stand to be improved.
>
> This gets more complex if you consider use with Proxy-Authenticate. This
> mostly gets into the theoretical since I have never heard of it being
> used in practice. It makes things complicated since in theory there
> could be multiple proxies on the path, and they of necessity challenge
> one at a time. To complete the request you then must supply a suitable
> credential for each of the proxies on the path. AFAIK that has never
> been satisfactorily explained. So I guess I would give you a pass if you
> put in a disclaimer that using this for Proxy-Authenticate is outside
> the scope of this document.
>


Ok.

Regards,
 Rifaat



>
>         Thanks,
>         Paul
>