Re: [Sip] Another Revised agenda for SIP et IETF 64

[Allison Mankin <[e-mail]>]

Hi,

> 
>         I think this is a reasonable place for the Area Director to 
>         speak a little more.  There's definitely a precedent for making room 
>         for existing types of SIM in the IETF-structured security designs. 
>         But why is this an issue for the SIP working group, 
>         once SIP has come up with a basic security design that has 
>         IETF-structured security in it? 
> 
>         ==> Thanks AD here, we think reason is since HTTP AKA-Digest appears here :)

Understood.  The first time that we extended Digest, we did do it with
a SIP WG document.  It sort of booted the security design.  Because
the original question asked by the AKA folks was whether this should be
HTTP-Digest-EAP-AKA, and there needed to be some discussion about why
not EAP (that was actually mostly with the Security Area, I recall)
and then some discussion to make sure that SIP Digest use was well thought
through (this was in 2002, a long time ago).

But when AKA folks needed to do HTTP AKA-Digest v2, this was not done as
a SIP document.  It was done as an independent AD-sponsored document
with security review.

> 
>         In my view, the Security Area needs to review your requirements 
>         and then your specification.  I would recommend that 
>         the document become an AD-sponsored individual submission, the 
>         same way that Digest-AKA was.  
> 
>         ==> we are not familiar with what's happened for Digest-AKA historically
> 
>         would like to understand more.

See above.
> 
>         I would be happy to ask Russ Housley to adopt this work, and 
>         ask SIP for advice to the extent any SIP issues come up. 
> 
>         ==> Thanks again
> 
>         Just reading a little, there have been enough attacks on CAVE, that 
>         though it's widely used, the tradeoff for the specification will 
>         be to make sure it states clearly what the risks are, and it's this 
>         stuff especially that makes it a non-SIP Informational with a 
>         SEC AD sponsor. 
> 
>         ==> I guess that here what you mean is like the Section of Security Consideration
> 
>         in RFC 3310.

Yes.

> 
>         One thing I still not clear is do you mean this analysis should be done in problem 
> 
>         statement or in solution.

I'd probably just do one document with both the problem statement and
the solution in it.

> 
>         Another thing is do you mean that solution could become non-SIP informational
> 
>         or problem statement could become non-SIP informational

I'd do one Informational document that is AD sponsored, a non-SIP Informational,
similar in content to draft-torvinen-http-digest-aka-v2-02.txt, which was
independent and AD-sponsored, and which is about to come out as RFC 4169.

Allison



_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip